Re: [JBoss-dev] Re: Shutdown behaves while using 8082 service

2001-10-20 Thread Peter Fagerlund

on 1-10-19 17.26, Peter Fagerlund at [EMAIL PROTECTED] wrote:


 There seem to be a fragmentation in how We behave in our MBeans with
 stop/destroy/unload and naming semantics...
 MQ seems to do some clean up in destroy and referencing Mbeans that then has
 already stopped/destroyed ... and so on ... I need to look at this some more
 ... together with You all ! ...

Here I was wrong the error messages was due to when destroying
ServiceController it destroys all its services contained and We just did
that outside of the ServiceController ... huh ... my mistake ... sorry ...

everything is clean now as I can se ... except for the name differences ...
in ServiceController and the MBeans server seen below ... (2)

 :name=StdJMSPool,service=ServerSessionPoolMBean
 JBOSS-SYSTEM:name=StdJMSPool,service=ServerSessionPoolMBean

/peter_f


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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceController.java

2001-10-20 Thread Peter Fagerlund

  User: peter_f 
  Date: 01/10/20 04:12:32

  Modified:src/main/org/jboss/system ServiceController.java
  Log:
  uncommeted out destroy for now - since that code is in the shutdown class enabeling 
filtering out some services - seems cleaner having that logic there for now
  
  Revision  ChangesPath
  1.10  +11 -1 jboss/src/main/org/jboss/system/ServiceController.java
  
  Index: ServiceController.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceController.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- ServiceController.java2001/10/08 01:38:13 1.9
  +++ ServiceController.java2001/10/20 11:12:32 1.10
  @@ -40,7 +40,7 @@
* @see org.jboss.system.Service
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
  - * @version $Revision: 1.9 $ p
  + * @version $Revision: 1.10 $ p
*
* bRevisions:/b p
*
  @@ -382,11 +382,20 @@
 log.info(Stopped  + serviceCounter +  services);
  }
   
  +
  /**
   * #Description of the Method
   */
  public void destroy()
  {
  +
  +// We now iterate the destroy one and one to be able to filter out
  +// some services and are handeling this code in the class Shutdown
  +// until we have a new (un)dependency mechanism ...  
  +
  +log.info(ServiceController destroy commented out for now ...);
  +
  +/*
 log.info(Destroying  + services.size() +  services);
   
 List servicesCopy = new ArrayList(services);
  @@ -415,6 +424,7 @@
 }
 
 log.info(Destroyed  + serviceCounter +  services);
  +  */
  }
   
  /**
  
  
  

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



[JBoss-dev] MDB and reconnecting

2001-10-20 Thread Konrad Kamiski



Hi!

I'm using JBoss 2.4.3 and MDB's, which are 
connected to MQSeries. I found out thatwhen MQSeries is going down the MDB 
is not trying to reconnect. The problem is that in 
org.jboss.ejb.plugins.jms.JMSContainerInvoker.ExceptionListenerImpl the 
notStoped (which should probably be notStopped) variable is always set to false. 
The comment, in which it's set to true (at declaration time), should probably be 
removed (that is, notStoped should be set to true). I also think that the time 
between reconnecting trials should be somehow configured (now it's fixed to 10 
seconds).

I also have another problem, which I think is more 
difficult (this should probably go to jboss-user, but since I'm here...). At 
deployment time if JMS server (MQSeries in my case) is not running the MDB will 
not deploy and therefore the whole application will not deploy at all. Is there 
any simple solution to that problem?

Thanks, Konrad Kamiñski



[JBoss-dev] CVS update: jboss/src/main/org/jboss/system Shutdown.java

2001-10-20 Thread Peter Fagerlund

  User: peter_f 
  Date: 01/10/20 04:40:08

  Modified:src/main/org/jboss/system Shutdown.java
  Log:
  added a flag for verbose name messages
  
  Revision  ChangesPath
  1.5   +42 -33jboss/src/main/org/jboss/system/Shutdown.java
  
  Index: Shutdown.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/Shutdown.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Shutdown.java 2001/10/19 15:36:15 1.4
  +++ Shutdown.java 2001/10/20 11:40:08 1.5
  @@ -27,7 +27,7 @@
*  
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
  - * @version $Revision: 1.4 $
  + * @version $Revision: 1.5 $
*/
   public class Shutdown
  implements MBeanRegistration, ShutdownMBean
  @@ -128,16 +128,19 @@
  {
 try
 {
  + // set to true for detailed name printouts
  +boolean verbose = false;
  +
   // get the deployed objects from ServiceController
ObjectName[] deployed = (ObjectName[]) server.invoke(
new ObjectName(JBOSS-SYSTEM:spine=ServiceController),
   getDeployed, new Object[0] , new String[0] );
   
  -List servicesCopy = Arrays.asList(deployed);
  + List servicesCopy = Arrays.asList(deployed);
ListIterator enum = servicesCopy.listIterator();
   ListIterator beanEnum = servicesCopy.listIterator();
  -ObjectName name = null;
  -String[] sig = { javax.management.ObjectName };
  + ObjectName name = null;
  + String[] sig = { javax.management.ObjectName };
   
   // filo ( first in last out )
   /*
  @@ -147,27 +150,30 @@
   
   // filter out some services here ?
   
  - }
  + }
   
   */
  - // Stop / Destroy / Unload all MBeans from ServiceController
  + // Stop / Destroy / Unload all MBeans from ServiceController
   
   // Stop
   while (enum.hasNext())
  - //while (enum.hasPrevious())
  - {
  + //while (enum.hasPrevious())
  + {
   name = (ObjectName)enum.next();
   //name = (ObjectName)enum.previous();
  - Object[] args = { name };
  - log.info(**Looking at MBean :  + 
name.getCanonicalName());
  + Object[] args = { name };
  +if(verbose)
  + log.info(**Looking at MBean :  + 
name.getCanonicalName());
// Stop services
   if(! name.getCanonicalName().equals(JMX:name=Connector,type=RMI)
! name.getCanonicalName().equals(Adaptor:name=html)
! name.getCanonicalName().equals(JBOSS-SYSTEM:service=Naming)
 )
   {
  -   log.info(**Stopping   MBean :  + 
name.getCanonicalName());
  -server.invoke(new 
ObjectName(JBOSS-SYSTEM:spine=ServiceController), stop, args , sig);
  + if(verbose)
  + log.info(**Stopping   MBean :  + 
name.getCanonicalName());
  + server.invoke(new ObjectName(JBOSS-SYSTEM:spine=ServiceController),
  + stop, args , sig);
   
  // Destroy services
   
  @@ -180,23 +186,24 @@
   while (enum.hasPrevious())
   //while (enum.hasNext())
{
  -name = (ObjectName)enum.previous();
  - //name = (ObjectName)enum.next();
  - Object[] args = { name };
  -log.info(**Looking at MBean :  + 
name.getCanonicalName());
  - // Destroy services
  -if(! name.getCanonicalName().equals(JMX:name=Connector,type=RMI)
  - ! name.getCanonicalName().equals(Adaptor:name=html)
  - ! name.getCanonicalName().equals(JBOSS-SYSTEM:service=Naming)
  -  )
  -{
  + name = (ObjectName)enum.previous();
  + //name = (ObjectName)enum.next();
  + Object[] args = { name };
  + if(verbose)
  + log.info(**Looking at MBean :  + 
name.getCanonicalName());
  + // Destroy services
  +if(! name.getCanonicalName().equals(JMX:name=Connector,type=RMI)
  + ! name.getCanonicalName().equals(Adaptor:name=html)
  + ! name.getCanonicalName().equals(JBOSS-SYSTEM:service=Naming)
  +   )
  +{
  +if(verbose)
log.info(**Destroying MBean :  + 
name.getCanonicalName());
  - server.invoke(new ObjectName(JBOSS-SYSTEM:spine=ServiceController), 
destroy, args , sig);
  +server.invoke(new ObjectName(JBOSS-SYSTEM:spine=ServiceController),
  + 

[JBoss-dev] CVS update: jboss/src/main/org/jboss/system Shutdown.java

2001-10-20 Thread Peter Fagerlund

  User: peter_f 
  Date: 01/10/20 06:36:12

  Modified:src/main/org/jboss/system Shutdown.java
  Log:
  trying to submit a formated file - sorry
  
  Revision  ChangesPath
  1.6   +164 -227  jboss/src/main/org/jboss/system/Shutdown.java
  
  Index: Shutdown.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/Shutdown.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Shutdown.java 2001/10/20 11:40:08 1.5
  +++ Shutdown.java 2001/10/20 13:36:12 1.6
  @@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
  +
   package org.jboss.system;
   
   import java.util.List;
  @@ -12,253 +13,189 @@
   import java.util.Set;
   import java.util.List;
   import java.util.ListIterator;
  -
   import javax.management.ObjectName;
   import javax.management.MBeanServer;
   import javax.management.MBeanRegistration;
   import javax.management.RuntimeMBeanException;
   import javax.management.RuntimeOperationsException;
  -
   import org.apache.log4j.Category;
   
   /**
* Shutdown service.  Installs a hook to cleanly shutdown the server and
* provides the ability to handle user shutdown requests.
  - *  
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
  - * @version $Revision: 1.5 $
  + * @version $Revision: 1.6 $
*/
  -public class Shutdown
  -   implements MBeanRegistration, ShutdownMBean
  -{
  -   // Constants -
  - 
  -   // Attributes 
  - 
  -   /** Instance logger. */
  -   private final Category log = Category.getInstance(Shutdown.class);
  - 
  -   /** The MBean server we are attached to. */
  -   private MBeanServer server;
  +public class Shutdown implements MBeanRegistration, ShutdownMBean {
  +// Constants -
  +// Attributes 
  +
  +/** Instance logger. */
  +private final Category log = Category.getInstance(Shutdown.class);
  +
  +/** The MBean server we are attached to. */
  +private MBeanServer server;
  +// Public  ---
  +
  +/** Shutdown the virtual machine and run shutdown hooks. */
  +public void shutdown() {
  +log.info(Shutting down);
  +System.exit(0); // This will execute the shutdown hook
  +}
  +
  +/** Forcibly terminates the currently running Java virtual machine. */
  +public void halt() {
  +System.err.println(Halting the system now!);
  +Runtime.getRuntime().halt(0);
  +}
  +// MBeanRegistration implementation --
  +
  +/**
  + * Saves a reference to the MBean server for later use and installs a shutdown 
hook.
  + * @param serverThe MBean server which we are going to be registered.
  + * @param name  The object name we have been configured to use.
  + * @return  Our preferred object name.
  + * @throws MalformedObjectNameException
  + */
  +public ObjectName preRegister(final MBeanServer server, final ObjectName name) 
throws Exception {
  +this.server = server;
  +try {
  +Runtime.getRuntime().addShutdownHook(
  +new Thread(JBoss Shutdown Hook) {
  +public void run() {
  +log.info(Shutting down all services);
  +System.out.println(Shutting down);
  +// Make sure all services are down properly
  +shutdownServices();
  +log.info(Shutdown complete);
  +System.out.println(Shutdown complete);
  +}
  +});
  +log.info(Shutdown hook added);
  +} catch (Throwable e) {
  +log.error(Could not add shutdown hook, e);
  +}
  +return name == null ? new ObjectName(OBJECT_NAME) : name;
  +}
   
  -   // Public  ---
  - 
  -   /**
  -* Shutdown the virtual machine and run shutdown hooks.
  -*/
  -   public void shutdown()
  -   {
  -  log.info(Shutting down);
  -  System.exit(0); // This will execute the shutdown hook
  -   }
  - 
  -   /**
  -* Forcibly terminates the currently running Java virtual machine.
  -*/
  -   public void halt()
  -   {
  -  System.err.println(Halting the system now!);
  -  Runtime.getRuntime().halt(0);
  -   }
  - 
  -   // MBeanRegistration implementation --
  - 
  -   /**
  -* Saves a reference to the MBean server for later use and installs
  -* a 

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge JDBCCMRFieldBridge.java

2001-10-20 Thread Dain Sundstrom

  User: dsundstrom
  Date: 01/10/20 09:14:57

  Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
JDBCCMRFieldBridge.java
  Log:
  Fixed bug where self relationships were not initializing correctly.
  
  Revision  ChangesPath
  1.8   +7 -1  
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMRFieldBridge.java
  
  Index: JDBCCMRFieldBridge.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMRFieldBridge.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JDBCCMRFieldBridge.java   2001/09/11 18:35:00 1.7
  +++ JDBCCMRFieldBridge.java   2001/10/20 16:14:57 1.8
  @@ -44,7 +44,7 @@
*  One for each role that entity has.   
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
  - * @version $Revision: 1.7 $
  + * @version $Revision: 1.8 $
*/
   public class JDBCCMRFieldBridge implements CMRFieldBridge {
  // -- Invocation messages --
  @@ -231,6 +231,12 @@
 // if the other side has been created intitialize the related data
 if(relatedManager.getEntityBridge() != null) {
initRelatedData(relatedManager.getEntityBridge());
  + relatedCMRField.initRelatedData(entity);
  +  } else if(manager == relatedManager) {
  + // self relation: must be handled special because
  + // the entity is not added to the manager until after
  + // all of the fields have been initialized.
  + initRelatedData(entity);
relatedCMRField.initRelatedData(entity);
 }
  }
  
  
  

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



[JBoss-dev] FAQ

2001-10-20 Thread Dain Sundstrom

Do we have a FAQ? If not, I think we should start one.

About every third day I get a message asking me what version of JBoss
supports CMP 2.0, or I get a message asking where 3.0 is.

I know this info is in the message archives, but I think it would be a good
thing to have a central place for a person to look.

Dain

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



RE: [JBoss-dev] FAQ

2001-10-20 Thread marc fleury

We have one under the developer links, I think it could go back under the
user links.

One of the problems is that few people maintain it so it tends to get out of
whack.

If you have some time you could prune it and I will gladly reinstate it.

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
|Sundstrom
|Sent: Saturday, October 20, 2001 12:26 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] FAQ
|
|
|Do we have a FAQ? If not, I think we should start one.
|
|About every third day I get a message asking me what version of JBoss
|supports CMP 2.0, or I get a message asking where 3.0 is.
|
|I know this info is in the message archives, but I think it would be a good
|thing to have a central place for a person to look.
|
|Dain
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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



Re: [JBoss-dev] FAQ

2001-10-20 Thread Peter Fagerlund

on 1-10-20 19.25, marc fleury at [EMAIL PROTECTED] wrote:

 We have one under the developer links, I think it could go back under the
 user links.
 
 One of the problems is that few people maintain it so it tends to get out of
 whack.
 
 If you have some time you could prune it and I will gladly reinstate it.

Could'ent we use the forum faq as place where when You feel You have a
general answer to related questions You would add that to the forum faq ?
A design that add fields the subject, version and a popupmeny for topics
covered in the faq ? ... and that was then presented as a presentation /
search if You are not logged in ...

/peter_f


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



RE: [JBoss-dev] FAQ

2001-10-20 Thread marc fleury

yes but the posting right now is not really limited to people maintaining
the FAQ,

I will try to modify the forums before leaving for Las Vegas.

marcf

|-Original Message-
|From: Peter Fagerlund [mailto:[EMAIL PROTECTED]]
|Sent: Saturday, October 20, 2001 3:56 PM
|To: marc fleury; Dain Sundstrom; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] FAQ
|
|
|on 1-10-20 19.25, marc fleury at [EMAIL PROTECTED] wrote:
|
| We have one under the developer links, I think it could go back under the
| user links.
|
| One of the problems is that few people maintain it so it tends
|to get out of
| whack.
|
| If you have some time you could prune it and I will gladly reinstate it.
|
|Could'ent we use the forum faq as place where when You feel You have a
|general answer to related questions You would add that to the forum faq ?
|A design that add fields the subject, version and a popupmeny for topics
|covered in the faq ? ... and that was then presented as a presentation /
|search if You are not logged in ...
|
|/peter_f
|


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



[JBoss-dev] Next week in Las Vegas

2001-10-20 Thread marc fleury

So next week we are going to be in Las Vegas.

It is going to be fun to regroup, meet people and do a kick ass show.  I
love the stage.

So we've got an almost sold out class with people from all over the world
and it seems that the US is finally flying again.

It is going to be a great show.

So anyway, Scott and I are the full week in Vegas, Andreas and Bill are
coming on wednesday (just in time to go see the blue man group).  So it
means you kids will be alone in the coming weeks. I trust you will behave
and if something bad really happens well you know where to find us (Bally's
on the strip).  But make no mistake, we won't really be there... the hotel
is a mental spaceship and I am taking the gang for a tour.  So it will feel
like we will be here, but we really won't be here.

What? I am not making any sense? that's ok, you'll understand one day.

Peace Love and good Code,

marcf



Marc Fleury
President
JBoss Group, LLC



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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Ole Husgaard

Hi,

Andreas Schaefer wrote:
 The last few times I tried to run the testsuite I got some many errors
 and failures that I was frustrated to go on.

Yes, this used to be really bad - getting better now.

 But to make it usefull I would like to have these items:
 - documentation how to prepare and run the testsuite

This is simple: The ant script in directory build has
a target testsuite that runs the entire test suite
and generates the reports.

 - more information about each test especially when it fails

Tricky. Often when a test fails, it is due to some other
bug then the one the test is testing for. But as the test
fails, we get file and line number information in the
test report, so looking up the source to see what the
test does is easy.

 - documentation how to write testsuites when I coded new feauters

We don't have that, but we have lots of working example
code in the test suite - ready to cut-n-paste and edit
to create tew tests and test suites.


Best Regards,

Ole Husgaard.

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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Ole Husgaard

Hi,

marc fleury wrote:
 so I not only second that but I think we should introduce speed tests that
 make sure that not only the functionality but also the performance is better
 or at least not degrading across commits.

Yes, this would be a good idea.

 I don't know if there is a way to automate that in Chris's test but if there
 was that would be absolutely kick ass.  When a test is done we would know
 immediately if the performance is going down because of a problem.

I don't think that JUnit can handle speed measurements the
way we want, as it only does pass/fail.
But it could be possible to write such a system.
We should probably have a baseline speed test not depending
on JBoss that never changes and use that to correct for
differences in speed of the machine used for testing.


It would also be nice if we had some database with the
historic results of individual tests run with the
automated daily test. This way, if someone finds out
that some test stopped running, he can look up the
database and find out which day it happened. It we
only have to look at committed changes for a single
day when something fails, it will be a lot easier to
fix. (D*nm that the automated tests no longer includes
detailed test failure information. Maybe there is
room for it again, now that the failure count is no
longer so high?)


But to make developers use the test suite it should
also be simple, straightforward and _fast_ to run.
Currently, on my 800MhZ Duron system, the test suite
takes about 40 minutes to run. This is so long that
it may scare some developers from running the suite.
Most of the time it runs stress tests that take a
long time.

Maybe it would be an idea to have another test target
that only includes basic functionality tests, and
that can run in a few minutes?
Chances are higher that developers will run tests if
it only takes a few minutes, and basic functionality
testing is better than no testing at all.


Best Regards,

Ole Husgaard.

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



[JBoss-dev] CVS update: jbosstest/src/stylesheets summary1a.xsl

2001-10-20 Thread Chris Kimpton

  User: kimptoc 
  Date: 01/10/20 13:36:54

  Modified:src/stylesheets summary1a.xsl
  Log:
  added some comments to the testing email
  
  Revision  ChangesPath
  1.2   +5 -0  jbosstest/src/stylesheets/summary1a.xsl
  
  Index: summary1a.xsl
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/stylesheets/summary1a.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- summary1a.xsl 2001/09/04 08:45:39 1.1
  +++ summary1a.xsl 2001/10/20 20:36:53 1.2
  @@ -68,6 +68,11 @@
   
   /xsl:if
   
  +PS BEFORE you commit, run the test suite.
  +
  +PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!
  +
  +Oh, and thanks - remember we love you too!
   
   /xsl:template
   
  
  
  

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



[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/interfaces HARMIClient.java

2001-10-20 Thread Bill Burke

  User: patriot1burke
  Date: 01/10/20 13:50:34

  Modified:src/main/org/jboss/ha/framework/interfaces HARMIClient.java
  Log:
  turned off System.out.println messages
  
  Revision  ChangesPath
  1.3   +55 -55
jbossmx/src/main/org/jboss/ha/framework/interfaces/HARMIClient.java
  
  Index: HARMIClient.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/interfaces/HARMIClient.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- HARMIClient.java  2001/10/02 04:05:56 1.2
  +++ HARMIClient.java  2001/10/20 20:50:34 1.3
  @@ -30,7 +30,7 @@
*
*   @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
*   @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
  - *   @version $Revision: 1.2 $
  + *   @version $Revision: 1.3 $
*
*   pbRevisions:/b
*
  @@ -48,81 +48,81 @@
  protected transient long currentViewId = 0;
  protected transient Object local = null;
  
  -   public HARMIClient ()
  +   public HARMIClient()
  {}
  
  -   public HARMIClient (ArrayList targets, LoadBalancePolicy policy, String key)
  +   public HARMIClient(ArrayList targets, LoadBalancePolicy policy, String key)
  {
 this.targets = targets;
 this.loadBalancePolicy = policy;
  -  this.loadBalancePolicy.init (this);  
  +  this.loadBalancePolicy.init(this);  
 this.key = key;
  }
  
  -   public HARMIClient (ArrayList targets,
  +   public HARMIClient(ArrayList targets,
  LoadBalancePolicy policy,
  String key,
  Object local)
  {
 this.targets = targets;
 this.loadBalancePolicy = policy;
  -  this.loadBalancePolicy.init (this);  
  +  this.loadBalancePolicy.init(this);  
 this.key = key;
 this.local = local;
  }
  
  -   public boolean isLocal ()
  +   public boolean isLocal()
  {
 return local != null;
  }
  
  -   public ArrayList getTargets ()
  +   public ArrayList getTargets()
  {
 return targets;
  }
  
  -   public void setTargets (ArrayList newTargets)
  +   public void setTargets(ArrayList newTargets)
  {
 synchronized(targets)
 {
  - targets.clear ();
  - targets.addAll (newTargets);
  + targets.clear();
  + targets.addAll(newTargets);
 }
  }
   
  
  -   public Object getRemoteTarget ()
  +   public Object getRemoteTarget()
  {
  -  System.out.println (number of targets:  + targets.size ());
  -  if (targets.size () == 0)
  +  //  System.out.println(number of targets:  + targets.size());
  +  if (targets.size() == 0)
 {
return null;
 }
 synchronized (targets)
 {
  - return loadBalancePolicy.chooseTarget (targets);
  + return loadBalancePolicy.chooseTarget(targets);
 }
  }
  
  -   public void remoteTargetHasFailed (Object target)
  +   public void remoteTargetHasFailed(Object target)
  {
  -  removeDeadTarget (target);
  +  removeDeadTarget(target);
  }
  
  -   protected void removeDeadTarget (Object target)
  +   protected void removeDeadTarget(Object target)
  {
 //System.out.println(Size before :  + Integer.toString(targets.length));
 if (targets != null)
 {
  - synchronized (targets)
  + synchronized(targets)
{
   //System.out.println(removeDeadTarget has been called);
  -int length = targets.size ();
  +int length = targets.size();
   for (int i=0; ilength; ++i)
   {
  -   if (targets.get (i) == target)
  +   if (targets.get(i) == target)
  {
  -  targets.remove (i);
  +  targets.remove(i);
 return;
  }
   }
  @@ -132,18 +132,18 @@
  }
   
   
  -   public Method findLocalMethod (Method method, Object[] args) throws Exception
  +   public Method findLocalMethod(Method method, Object[] args) throws Exception
  {
 return method;
  }
  
  -   public Object invoke (Object proxy, Method method, Object[] args) throws 
Throwable
  +   public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
  {
 // The isLocal call is handled by the proxy
 //
  -  if (method.getName ().equals (isLocal)  (args == null || args.length == 
0))
  +  if (method.getName().equals(isLocal)  (args == null || args.length == 0))
 {
  - return method.invoke (this, args);
  + return method.invoke(this, args);
 }
 
 // we try to optimize the call locally first
  @@ -152,36 +152,36 @@
 {
try
 

[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java

2001-10-20 Thread Bill Burke

  User: patriot1burke
  Date: 01/10/20 13:51:33

  Modified:src/main/org/jboss/ha/framework/server HAPartitionImpl.java
  Log:
  added timeout to rpcs
  
  Revision  ChangesPath
  1.6   +2 -2  
jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
  
  Index: HAPartitionImpl.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- HAPartitionImpl.java  2001/10/10 20:02:05 1.5
  +++ HAPartitionImpl.java  2001/10/20 20:51:33 1.6
  @@ -56,7 +56,7 @@
*
*   @author [EMAIL PROTECTED]
*   @author [EMAIL PROTECTED]
  - *   @version $Revision: 1.5 $
  + *   @version $Revision: 1.6 $
*
* pbRevisions:/bbr
*/
  @@ -69,7 +69,7 @@
  
  protected String partitionName;
  protected String nodeName;
  -   protected int timeout = 0;
  +   protected int timeout = 500;
  
  protected JChannel channel = null;
  
  
  
  

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



[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server DistributedReplicantManagerImpl.java

2001-10-20 Thread Bill Burke

  User: patriot1burke
  Date: 01/10/20 13:51:46

  Modified:src/main/org/jboss/ha/framework/server
DistributedReplicantManagerImpl.java
  Log:
  cleaned up some stuff.
  
  Revision  ChangesPath
  1.5   +94 -7 
jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java
  
  Index: DistributedReplicantManagerImpl.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- DistributedReplicantManagerImpl.java  2001/10/17 23:36:34 1.4
  +++ DistributedReplicantManagerImpl.java  2001/10/20 20:51:46 1.5
  @@ -25,12 +25,13 @@
*
*   @author [EMAIL PROTECTED]
*   @author [EMAIL PROTECTED]
  - *   @version $Revision: 1.4 $
  + *   @version $Revision: 1.5 $
*
* pbRevisions:/bbr
*/
   public class DistributedReplicantManagerImpl
  implements DistributedReplicantManager,
  +  HAPartition.HAPartitionStateTransfer,
 HAPartition.HAMembershipListener
   {
  protected HashMap localReplicants = new HashMap();
  @@ -55,6 +56,10 @@
 partition.registerRPCHandler(SERVICE_NAME, this);
 log.debug(registerMembershipListener);
 partition.registerMembershipListener(this);
  +  /*
  +  log.debug (subscribeToStateTransferEvents);
  +  partition.subscribeToStateTransferEvents (SERVICE_NAME, this);
  +  */
  }
  
  public void start() throws Exception
  @@ -70,12 +75,77 @@
  public void stop() throws Exception
  {
 UnicastRemoteObject.unexportObject(this, true);
  +  partition.unsubscribeFromStateTransferEvents(SERVICE_NAME, this);
  }
  
  +   /
  +   // State transfer API
  +   /
  +
  +   /**
  +* State Transfer protocol required method.  Merges localReplicants with 
replicants and
  +* returns this hashmap.
  +*/
  +   public Serializable getCurrentState()
  +   {
  +  try
  +  {
  + HashMap rtn = new HashMap();
  + synchronized (replicants)
  + {
  +rtn.putAll(replicants);
  +synchronized (localReplicants)
  +{
  +   Iterator keys = localReplicants.keySet().iterator();
  +   while (keys.hasNext())
  +   {
  +  String key = (String)keys.next();
  +  Serializable rep = (Serializable)localReplicants.get(key);
  +  addReplicant(rtn, key, partition.getNodeName(), rep);
  +   }
  +}
  + }
  + return rtn;
  +  }
  +  catch (Exception ex)
  +  {
  + log.error(getCurrentState failed, ex);
  +  }
  +  return null;
  +   }
  +   
  +   public void setCurrentState(Serializable newState)
  +   {
  +  if (newState == null) return;
  +  try
  +  {
  + synchronized (replicants)
  + {
  +replicants.clear ();
  +replicants.putAll ((HashMap)newState);
  +if (keyListeners.size ()  0)
  +   cleanupKeyListeners ();
  + }
  + Iterator keys = replicants.keySet().iterator();
  + while (keys.hasNext())
  + {
  +String key = (String)keys.next();
  +notifyKeyListeners(key, lookupReplicants(key));
  + }
  +  }
  +  catch (Exception ex)
  +  {
  + log.error(setCurrentState failed, ex);
  +  }
  +   }
  + 
  
  // Group membership API
  
   
  +   /**
  +* This is deprecated for now.  We may resurrect it.
  +*/
  protected class MergeMembers extends Thread
  {
 public void run()
  @@ -84,6 +154,9 @@
 }
  }
   
  +   /**
  +* This is deprecated for now.  We may resurrect it.
  +*/
  protected void mergeMembers()
  {
 try
  @@ -94,6 +167,11 @@
for (int i = 0; i  rsp.size(); i++)
{
   Object[] objs = (Object[])rsp.get(i);
  +if (objs == null)
  +{
  +   log.warn(mergeMembers received NULL from lookupLocalReplicants);
  +   continue;
  +}
   String node = (String)objs[0];
   HashMap replicants = (HashMap)objs[1];
   Iterator keys = replicants.keySet().iterator();
  @@ -181,18 +259,27 @@
  // DistributedReplicantManager API
  ///
  
  +   /**
  +* Add a replicant to the replicants map.
  +*/
  protected void addReplicant(String key, String nodeName, Serializable replicant)
  {
  -  log.info(_add( + key + ,  + nodeName);
  -
  -  synchronized(replicants)
  +  addReplicant(replicants, key, nodeName, replicant);
  +   }
  +  

[JBoss-dev] CVS update: jbossmx/etc slsb.java jnditester.java jboss.xml cluster-service.xml

2001-10-20 Thread Bill Burke

  User: patriot1burke
  Date: 01/10/20 14:00:14

  Added:   etc  slsb.java jnditester.java jboss.xml
cluster-service.xml
  Log:
  example files
  
  Revision  ChangesPath
  1.1  jbossmx/etc/slsb.java
  
  Index: slsb.java
  ===
  import java.rmi.*;
  import java.awt.*;
  import java.util.*;
  import javax.ejb.*;
  import javax.naming.*;
  import java.awt.event.*;
  import java.util.*;
  import java.lang.*;
  import java.io.*;
  import org.jboss.test.testbean.interfaces.StatelessSessionHome;
  import org.jboss.test.testbean.interfaces.StatelessSession;
  import org.jboss.test.testbean.interfaces.EnterpriseEntityHome;
  import org.jboss.test.testbean.interfaces.EnterpriseEntity;
  import javax.ejb.DuplicateKeyException;
  import javax.ejb.Handle;
  import javax.ejb.EJBMetaData;
  import javax.ejb.EJBHome;
  import javax.ejb.HomeHandle;
  
  public class slsb
  {
  public static void main(String[] args)
  {
  try
  {
  Properties p = new Properties();
  
  p.put(Context.INITIAL_CONTEXT_FACTORY, 
org.jnp.interfaces.NamingContextFactory);
  p.put(Context.PROVIDER_URL, 10.10.10.13:1100,10.10.10.14:1100);
  // p.put(Context.PROVIDER_URL, localhost:1100);
  p.put(Context.URL_PKG_PREFIXES, org.jboss.naming:org.jnp.interfaces);
  InitialContext ctx = new InitialContext(p);
  
  StatelessSessionHome  statelessSessionHome =  (StatelessSessionHome) 
ctx.lookup(nextgen.StatelessSession);
  EnterpriseEntityHome  cmpHome =  
(EnterpriseEntityHome)ctx.lookup(nextgen.EnterpriseEntity);
  StatelessSession statelessSession = statelessSessionHome.create();
  EnterpriseEntity cmp = null;
  try
  {
 cmp = cmpHome.findByPrimaryKey(bill);
  }
  catch (Exception ex)
  {
 cmp = cmpHome.create(bill);
  }
  int count = 0;
  while (true)
  {
 System.out.println(statelessSession.callBusinessMethodB());
 try
 {
cmp.setOtherField(count++);
 }
 catch (Exception ex)
 {
System.out.println(exception, trying to create it:  + ex);
cmp = cmpHome.create(bill);
cmp.setOtherField(count++);
 }
 System.out.println(Entity:  + cmp.getOtherField());
 Thread.sleep(2000);
  }
  }
  catch (NamingException nex)
  {
 if (nex.getRootCause() != null)
 {
nex.getRootCause().printStackTrace();
 }
  }
  catch (Exception ex)
  {
  ex.printStackTrace();
  }
  }
  }
  
  
  
  1.1  jbossmx/etc/jnditester.java
  
  Index: jnditester.java
  ===
  import java.rmi.*;
  import java.awt.*;
  import java.util.*;
  import javax.ejb.*;
  import javax.naming.*;
  import java.awt.event.*;
  import java.util.*;
  import java.lang.*;
  import java.io.*;
  
  public class jnditester
  {
  public static void main(String[] args)
  {
  try
  {
  Properties p = new Properties();
  
  p.put(Context.INITIAL_CONTEXT_FACTORY, 
org.jnp.interfaces.NamingContextFactory);
  p.put(Context.PROVIDER_URL, 10.10.10.13:1100,10.10.10.14:1100);
  //p.put(Context.PROVIDER_URL, localhost:1100);
  p.put(Context.URL_PKG_PREFIXES, org.jboss.naming:org.jnp.interfaces);
  InitialContext ctx = new InitialContext(p);
  String hello = hello world;
  
  try
  {
  String found = (String)ctx.lookup(testit);
  }
  catch (NameNotFoundException nfe)
  {
  System.out.println(creating testit!!!);
  ctx.bind(testit, hello);
  }
  
  while (true)
  {
  String found = null;
  try
  {
  found = (String)ctx.lookup(testit);
  System.out.println(found:  + found);
  }
  catch (NameNotFoundException nfe)
  {
  System.err.println(could not find testit);
  }
  Thread.sleep(2000);
  }
  }
  catch (Exception ex)
  {
  ex.printStackTrace();
  }
  }
  }
  
  
  
  1.1  jbossmx/etc/jboss.xml
  
  Index: jboss.xml
  

[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/tm/plugins/tyrex TransactionManagerService.java TransactionManagerServiceMBean.java

2001-10-20 Thread Scott M Stark

  User: starksm 
  Date: 01/10/20 14:01:43

  Modified:varia/src/main/org/jboss/tm/plugins/tyrex
TransactionManagerService.java
TransactionManagerServiceMBean.java
  Log:
  Clean up the imports and the handling of the domain config file as
  either a URL or classpath resource.
  
  Revision  ChangesPath
  1.4   +32 -19
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerService.java
  
  Index: TransactionManagerService.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerService.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TransactionManagerService.java2001/09/01 19:50:29 1.3
  +++ TransactionManagerService.java2001/10/20 21:01:43 1.4
  @@ -7,15 +7,10 @@
   
   package org.jboss.tm.plugins.tyrex;
   
  -import java.io.File;
  +import java.io.IOException;
  +import java.net.MalformedURLException;
   import java.net.URL;
  -import java.rmi.server.UnicastRemoteObject;
  -import java.rmi.RemoteException;
  -import java.rmi.ServerException;
  -import java.util.ArrayList;
  -import java.util.Iterator;
   import java.util.Hashtable;
  -
   import javax.naming.InitialContext;
   import javax.naming.Context;
   import javax.naming.Reference;
  @@ -29,12 +24,9 @@
   
   import javax.transaction.TransactionManager;
   import tyrex.tm.TransactionDomain;
  -import org.omg.CosTransactions.PropagationContext;
   import org.omg.CosTransactions.TransactionFactory;
  -import org.omg.CosTSPortability.Sender;
  -import org.omg.CosTSPortability.Receiver;
   
  -import org.jboss.system.ServiceMBeanSupport;
  +import org.jboss.util.ServiceMBeanSupport;
   
   /**
*  This is a JMX service which manages the Tyrex TransactionManager 
(tyrex.exolab.org).
  @@ -43,7 +35,7 @@
*
*  @see TyrexTransactionPropagationContextManager, tyrex.tm.TransactionDomain
*  @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
  - *  @version $Revision: 1.3 $
  + *  @version $Revision: 1.4 $
*/
   public class TransactionManagerService
  extends ServiceMBeanSupport
  @@ -60,7 +52,7 @@
   
  MBeanServer server;
   
  -   String config_file = domain.xml;
  +   String configFile = domain.xml;
   
   
  // Static 
  @@ -89,7 +81,7 @@
  {
 // Create txDomain singleton if we did not do it yet.
 if (txDomain == null) {
  -txDomain = tyrex.tm.TransactionDomain.createDomain( config_file );
  +txDomain = tyrex.tm.TransactionDomain.createDomain( configFile );
   txDomain.recover();
   tm = txDomain.getTransactionManager();
   txFactory = txDomain.getTransactionFactory();
  @@ -128,13 +120,34 @@
 }
  }
   
  -  public String getConfigFileName() {
  -return this.config_file;
  +  public String getConfigFileName()
  +  {
  +return this.configFile;
 }
   
  -  public void setConfigFileName(String name) {
  -this.config_file = name;
  -  }
  +   public void setConfigFileName(String name) throws IOException
  +   {
  +  // See if the name is a URL
  +  try
  +  {
  + URL url = new URL(name);
  + configFile = url.toExternalForm();
  +  }
  +  catch(MalformedURLException e)
  +  {
  + // Try to resolve the name as a classpath resource
  + ClassLoader loader = Thread.currentThread().getContextClassLoader();
  + URL url = loader.getResource(name);
  + if( url == null )
  + {
  +String msg = Failed to find name: +name+ as either a URL or a 
classpath resource;
  +category.error(msg);
  +throw new IOException(msg);
  + }
  + configFile = url.toExternalForm();
  +  }
  +  category.info(Using configFile: +configFile);
  +   }
   
  // ObjectFactory implementation --
   
  
  
  
  1.3   +4 -2  
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerServiceMBean.java
  
  Index: TransactionManagerServiceMBean.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerServiceMBean.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TransactionManagerServiceMBean.java   2001/08/30 02:42:38 1.2
  +++ TransactionManagerServiceMBean.java   2001/10/20 21:01:43 1.3
  @@ -7,13 +7,15 @@
   
   package org.jboss.tm.plugins.tyrex;
   
  +import java.io.IOException;
  +
   /**
*   MBean interface for the Tyrex TransactionManager
*   (not all calls are implemented)
*
*   @see TransactionManagerService
*   @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
  - *   @version 

[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/plugins/tyrex TransactionManagerService.java TransactionManagerServiceMBean.java

2001-10-20 Thread Scott M Stark

  User: starksm 
  Date: 01/10/20 14:02:15

  Modified:src/main/org/jboss/tm/plugins/tyrex Tag: Branch_2_4
TransactionManagerService.java
TransactionManagerServiceMBean.java
  Log:
  Clean up the imports and the handling of the domain config file as
  either a URL or classpath resource.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.4.1   +101 -79   
jboss/src/main/org/jboss/tm/plugins/tyrex/Attic/TransactionManagerService.java
  
  Index: TransactionManagerService.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/tm/plugins/tyrex/Attic/TransactionManagerService.java,v
  retrieving revision 1.1
  retrieving revision 1.1.4.1
  diff -u -r1.1 -r1.1.4.1
  --- TransactionManagerService.java2001/05/22 22:12:57 1.1
  +++ TransactionManagerService.java2001/10/20 21:02:15 1.1.4.1
  @@ -4,18 +4,12 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
  -
   package org.jboss.tm.plugins.tyrex;
   
  -import java.io.File;
  +import java.io.IOException;
  +import java.net.MalformedURLException;
   import java.net.URL;
  -import java.rmi.server.UnicastRemoteObject;
  -import java.rmi.RemoteException;
  -import java.rmi.ServerException;
  -import java.util.ArrayList;
  -import java.util.Iterator;
   import java.util.Hashtable;
  -
   import javax.naming.InitialContext;
   import javax.naming.Context;
   import javax.naming.Reference;
  @@ -29,12 +23,8 @@
   
   import javax.transaction.TransactionManager;
   import tyrex.tm.TransactionDomain;
  -import org.omg.CosTransactions.PropagationContext;
   import org.omg.CosTransactions.TransactionFactory;
  -import org.omg.CosTSPortability.Sender;
  -import org.omg.CosTSPortability.Receiver;
   
  -import org.jboss.logging.Logger;
   import org.jboss.util.ServiceMBeanSupport;
   
   /**
  @@ -44,7 +34,7 @@
*
*  @see TyrexTransactionPropagationContextManager, tyrex.tm.TransactionDomain
*  @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
  - *  @version $Revision: 1.1 $
  + *  @version $Revision: 1.1.4.1 $
*/
   public class TransactionManagerService
  extends ServiceMBeanSupport
  @@ -56,23 +46,23 @@
  public static String JNDI_TPC_RECEIVER = java:/TPCReceiver;
  public static String JNDI_IMPORTER = 
java:/TransactionPropagationContextImporter;
  public static String JNDI_EXPORTER = 
java:/TransactionPropagationContextExporter;
  -
  +   
  // Attributes 
  -
  +   
  MBeanServer server;
  -
  -   String config_file = domain.xml;
  -
  -
  +   /** The location of the Tyrex domain configuration file */
  +   String configFile = domain.xml;
  +   
  +   
  // Static 
  -
  +   
  static TransactionDomain txDomain = null;
  static TransactionManager tm = null;
  static TransactionFactory txFactory = null; //implements Sender and Receiver as 
well
  static TyrexTransactionPropagationContextManager tpcManager = null;
  -
  +   
  // ServiceMBeanSupport overrides -
  -
  +   
  public String getName()
  {
 return Tyrex Transaction manager;
  @@ -89,26 +79,28 @@
 throws Exception
  {
 // Create txDomain singleton if we did not do it yet.
  -  if (txDomain == null) {
  -txDomain = tyrex.tm.TransactionDomain.createDomain( config_file );
  -txDomain.recover();
  -tm = txDomain.getTransactionManager();
  -txFactory = txDomain.getTransactionFactory();
  +  if (txDomain == null)
  +  {
  + txDomain = tyrex.tm.TransactionDomain.createDomain( configFile );
  + txDomain.recover();
  + tm = txDomain.getTransactionManager();
  + txFactory = txDomain.getTransactionFactory();
 }
  -
  +  
 // Bind reference to TM in JNDI
 // Tyrex TM does not implement the tx importer and exporter
 // interfaces. These are handled through a different class.
 bindRef(JNDI_NAME, javax.transaction.TransactionManager);
 bindRef(JNDI_TPC_SENDER, org.omg.CosTSPortability.Sender);
 bindRef(JNDI_TPC_RECEIVER, org.omg.CosTSPortability.Receiver);
  -
  +  
 // This Manager implements the importer and exporter interfaces
 // but relies on the org.omg.CosTSPortability Sender and Receiver
 // to be bound in the JNDI as TPCSender and TPCReceiver
 // so we can initialize it only after we bind these names to JNDI
  -  if (tpcManager == null) {
  -tpcManager = new TyrexTransactionPropagationContextManager();
  +  if (tpcManager == null)
  +  {
  + tpcManager = new TyrexTransactionPropagationContextManager();
 }
 

[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml

2001-10-20 Thread Scott M Stark

  User: starksm 
  Date: 01/10/20 14:04:01

  Modified:src/etc/conf/default Tag: Branch_2_4 jboss.jcml
  Log:
  Update the tyrex configuration to specific the ConfigFile attribute as a
  classpath resource rather than a relative file path
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.40.2.9  +1 -1  jboss/src/etc/conf/default/Attic/jboss.jcml
  
  Index: jboss.jcml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/Attic/jboss.jcml,v
  retrieving revision 1.40.2.8
  retrieving revision 1.40.2.9
  diff -u -r1.40.2.8 -r1.40.2.9
  --- jboss.jcml2001/09/30 22:08:42 1.40.2.8
  +++ jboss.jcml2001/10/20 21:04:01 1.40.2.9
  @@ -41,7 +41,7 @@
  instead of the org.jboss.tm.TransactionManagerService and comment out
  the TransactionManagerService above   
 mbean code=org.jboss.tm.plugins.tyrex.TransactionManagerService 
name=DefaultDomain:service=TransactionManager
  -attribute name=ConfigFileName../conf/default/domain.xml/attribute
  +attribute name=ConfigFileNamedomain.xml/attribute
 /mbean
 --
   
  
  
  

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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Scott M Stark

A non-stress target already exists and is called tests-unit. It does not
include any of the stress testing and runs in 5.5 minutes on a PIII 850MHz
single processor box:

testsuite 1729./build.sh tests-unit
...
BUILD SUCCESSFUL

Total time: 5 minutes 23 seconds

testsuite 1731./build.sh -projecthelp 
Searching for build.xml ...
Buildfile: /home/starksm/cvsroot/Main/jboss-all/testsuite/build.xml
Default target:

 main  Executes the default target (most).

Main targets:

 all   Builds everything.
 clean Cleans up most generated files.
 clobber   Cleans up all generated files.
 compile   Compile all source files.
 docs  Builds all documentation.
 jars  Builds all jar files.
 main  Executes the default target (most).
 most  Builds almost everything.
 one-test  Execute a single test.
 release-all   Builds a distribution for each archive type.
 release-tar   Builds a TAR release distribution.
 release-tgz   Builds a TAR-GZIP release distribution.
 release-zip   Builds a ZIP release distribution.
 reports   Generates all reports.
 test  Execute a single test.
 tests Execute all tests.
 tests-stress  Execute all stress tests.
 tests-unitExecute all unit tests.

 But to make developers use the test suite it should
 also be simple, straightforward and _fast_ to run.
 Currently, on my 800MhZ Duron system, the test suite
 takes about 40 minutes to run. This is so long that
 it may scare some developers from running the suite.
 Most of the time it runs stress tests that take a
 long time.
 
 Maybe it would be an idea to have another test target
 that only includes basic functionality tests, and
 that can run in a few minutes?
 Chances are higher that developers will run tests if
 it only takes a few minutes, and basic functionality
 testing is better than no testing at all.
 



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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Scott M Stark

See if this is of any use for performance testing:

JUnitPerf is a collection of JUnit test decorators used to measure the
performance and scalability of functionality contained within existing JUnit
tests.
http://www.clarkware.com/software/JUnitPerf.html

- Original Message -
From: Ole Husgaard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, October 20, 2001 1:40 PM
Subject: Re: [JBoss-dev] Please run the test suite before committing.



 I don't think that JUnit can handle speed measurements the
 way we want, as it only does pass/fail.
 But it could be possible to write such a system.
 We should probably have a baseline speed test not depending
 on JBoss that never changes and use that to correct for
 differences in speed of the machine used for testing.




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



RE: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread marc fleury

yes I agree, it is going to be critical for the final push on the Rabbit
(target orbit x-mass)

I think putting the fast tests in a target and making it mandatory for
users to test is a good idea.  Then the full 40min test suite should be run
at night only, probably from chris's setup.  Then I believe that reporting
*and monitoring* the time it takes to run the whole suite* is going to be an
interesting time.

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Saturday, October 20, 2001 5:39 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Please run the test suite before committing.
|
|
|A non-stress target already exists and is called tests-unit. It does not
|include any of the stress testing and runs in 5.5 minutes on a PIII 850MHz
|single processor box:
|
|testsuite 1729./build.sh tests-unit
|...
|BUILD SUCCESSFUL
|
|Total time: 5 minutes 23 seconds
|
|testsuite 1731./build.sh -projecthelp
|Searching for build.xml ...
|Buildfile: /home/starksm/cvsroot/Main/jboss-all/testsuite/build.xml
|Default target:
|
| main  Executes the default target (most).
|
|Main targets:
|
| all   Builds everything.
| clean Cleans up most generated files.
| clobber   Cleans up all generated files.
| compile   Compile all source files.
| docs  Builds all documentation.
| jars  Builds all jar files.
| main  Executes the default target (most).
| most  Builds almost everything.
| one-test  Execute a single test.
| release-all   Builds a distribution for each archive type.
| release-tar   Builds a TAR release distribution.
| release-tgz   Builds a TAR-GZIP release distribution.
| release-zip   Builds a ZIP release distribution.
| reports   Generates all reports.
| test  Execute a single test.
| tests Execute all tests.
| tests-stress  Execute all stress tests.
| tests-unitExecute all unit tests.
|
| But to make developers use the test suite it should
| also be simple, straightforward and _fast_ to run.
| Currently, on my 800MhZ Duron system, the test suite
| takes about 40 minutes to run. This is so long that
| it may scare some developers from running the suite.
| Most of the time it runs stress tests that take a
| long time.
|
| Maybe it would be an idea to have another test target
| that only includes basic functionality tests, and
| that can run in a few minutes?
| Chances are higher that developers will run tests if
| it only takes a few minutes, and basic functionality
| testing is better than no testing at all.
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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



RE: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Bill Burke

We shouldn't be afraid to publicly flog anybody who breaks the mainline.

BTW, Ole, was I the one who broke the mainline?


Bill


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



RE: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread marc fleury

| I don't think that JUnit can handle speed measurements the
| way we want, as it only does pass/fail.
| But it could be possible to write such a system.
| We should probably have a baseline speed test not depending
| on JBoss that never changes and use that to correct for
| differences in speed of the machine used for testing.

we don't need something very complex, even just the simple test from the
tomcat installation are enough to measure theoretical throughput on the bare
container.  I would plug in fake persistence engines so that we are really
looking at **container** numbers and not **serialization/db** number.

Then there needs to be a series of tests for the persistence engines.  While
the time on the container has been fairly stable the time on the cmp engines
can vary greatly.  Since 80% of the time is spent in these stacks (queries
with large sets etc) it really impacts the performance a lot. These tests
should substract the measured time on container stacks and just measure the
CMP time.

marcf


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



RE: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread marc fleury

hmmm I wouldn't point any finger, we all broke it at one point or another,

marcf


|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Saturday, October 20, 2001 5:52 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Please run the test suite before committing.
|
|
|We shouldn't be afraid to publicly flog anybody who breaks the mainline.
|
|BTW, Ole, was I the one who broke the mainline?
|
|
|Bill
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development

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



[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjboss.xml

2001-10-20 Thread Bill Burke

  User: patriot1burke
  Date: 01/10/20 15:09:35

  Modified:src/etc/conf/default standardjboss.xml
  Log:
  changed default Clustered entity bean commit-option to B from A
  
  Revision  ChangesPath
  1.22  +3 -3  jboss/src/etc/conf/default/standardjboss.xml
  
  Index: standardjboss.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- standardjboss.xml 2001/10/18 20:03:42 1.21
  +++ standardjboss.xml 2001/10/20 22:09:35 1.22
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: standardjboss.xml,v 1.21 2001/10/18 20:03:42 vharcq Exp $ --
  +!-- $Id: standardjboss.xml,v 1.22 2001/10/20 22:09:35 patriot1burke Exp $ --
   
   jboss
  enforce-ejb-restrictionsfalse/enforce-ejb-restrictions
  @@ -182,7 +182,7 @@
MaximumSize100/MaximumSize
MinimumSize10/MinimumSize
 /container-pool-conf
  -  commit-optionA/commit-option
  +  commit-optionB/commit-option
 /container-configuration
   
 container-configuration
  @@ -478,7 +478,7 @@
MaximumSize100/MaximumSize
MinimumSize10/MinimumSize
 /container-pool-conf
  -  commit-optionA/commit-option
  +  commit-optionB/commit-option
 /container-configuration
   
 container-configuration
  
  
  

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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntityInstanceInterceptor.java EntityLockInterceptor.java EntityMultiInstanceSynchronizationInterceptor.java StatelessSessionInstanceInterceptor.java TxInterceptorBMT.java

2001-10-20 Thread Scott M Stark

  User: starksm 
  Date: 01/10/20 15:13:22

  Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
EntityInstanceInterceptor.java
EntityLockInterceptor.java
EntityMultiInstanceSynchronizationInterceptor.java
StatelessSessionInstanceInterceptor.java
TxInterceptorBMT.java
  Log:
  Remove the unused javax.transaction.* imports.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.30.2.4  +1 -5  
jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java
  
  Index: EntityInstanceInterceptor.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java,v
  retrieving revision 1.30.2.3
  retrieving revision 1.30.2.4
  diff -u -r1.30.2.3 -r1.30.2.4
  --- EntityInstanceInterceptor.java2001/10/18 20:32:39 1.30.2.3
  +++ EntityInstanceInterceptor.java2001/10/20 22:13:22 1.30.2.4
  @@ -19,11 +19,7 @@
   import javax.ejb.RemoveException;
   import javax.ejb.EntityBean;
   import javax.transaction.Status;
  -import javax.transaction.Synchronization;
   import javax.transaction.Transaction;
  -import javax.transaction.TransactionManager;
  -import javax.transaction.RollbackException;
  -import javax.transaction.SystemException;
   
   import org.jboss.ejb.Container;
   import org.jboss.ejb.BeanLock;
  @@ -61,7 +57,7 @@
   * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
   * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
   * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
  -* @version $Revision: 1.30.2.3 $
  +* @version $Revision: 1.30.2.4 $
   *
   * pbRevisions:/bbr
   * pb2001/06/28: marcf/b
  
  
  
  1.5.4.2   +156 -162  jboss/src/main/org/jboss/ejb/plugins/EntityLockInterceptor.java
  
  Index: EntityLockInterceptor.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityLockInterceptor.java,v
  retrieving revision 1.5.4.1
  retrieving revision 1.5.4.2
  diff -u -r1.5.4.1 -r1.5.4.2
  --- EntityLockInterceptor.java2001/09/04 01:51:07 1.5.4.1
  +++ EntityLockInterceptor.java2001/10/20 22:13:22 1.5.4.2
  @@ -1,162 +1,156 @@
  -/*
  -* JBoss, the OpenSource J2EE webOS
  -*
  -* Distributable under LGPL license.
  -* See terms of license at gnu.org.
  -*/
  -package org.jboss.ejb.plugins;
  -
  -import java.lang.reflect.Method;
  -import java.rmi.RemoteException;
  -import java.util.Map;
  -import java.util.HashMap;
  -import java.util.ArrayList;
  -
  -import javax.ejb.EJBObject;
  -import javax.ejb.CreateException;
  -import javax.ejb.EJBException;
  -import javax.ejb.NoSuchEntityException;
  -import javax.ejb.RemoveException;
  -import javax.ejb.EntityBean;
  -import javax.transaction.Status;
  -import javax.transaction.Synchronization;
  -import javax.transaction.Transaction;
  -import javax.transaction.TransactionManager;
  -import javax.transaction.RollbackException;
  -import javax.transaction.SystemException;
  -
  -import org.jboss.ejb.Container;
  -import org.jboss.ejb.BeanLock;
  -import org.jboss.ejb.BeanLockManager;
  -import org.jboss.ejb.EntityContainer;
  -import org.jboss.ejb.EntityPersistenceManager;
  -import org.jboss.ejb.EntityEnterpriseContext;
  -import org.jboss.ejb.EnterpriseContext;
  -import org.jboss.ejb.InstanceCache;
  -import org.jboss.ejb.InstancePool;
  -import org.jboss.ejb.MethodInvocation;
  -import org.jboss.ejb.CacheKey;
  -import org.jboss.logging.log4j.JBossCategory;
  -import org.jboss.metadata.EntityMetaData;
  -import org.jboss.tm.TxManager;
  -
  -/**
  - * The lock interceptors role is to schedule thread wanting to invoke method on a 
target bean
  - *
  -* pThe policies for implementing scheduling (pessimistic locking etc) is 
implemented by pluggable
  -*locks
  -*
  -* pWe also implement serialization of calls in here (this is a spec
  -*requirement). This is a fine grained notify, notifyAll mechanism. We
  -*notify on ctx serialization locks and notifyAll on global transactional
  -*locks.
  -*   
  -* pbWARNING: critical code/b, get approval from senior developers
  -*before changing.
  -*
  -* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
  -* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
  -* @version $Revision: 1.5.4.1 $
  -*
  -* pbRevisions:/bbr
  -* pb2001/07/30: marcf/b
  -* ol
  -*   liInitial revision
  -*   liFactorization of the lock out of the context in cache
  -*   liThe new locking is implement as scheduling in the lock which allows for 
pluggable locks
  -* /ol
  -* pb2001/08/07: billb/b
  -* ol
  -*   liRemoved while loop and moved it to SimplePessimisticEJBLock where it 
belongs.
  -* /ol
  -*/
  -public class EntityLockInterceptor
  -   extends 

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/mdb/test MDBUnitTestCase.java

2001-10-20 Thread Ole Husgaard

  User: sparre  
  Date: 01/10/20 15:25:59

  Modified:src/main/org/jboss/test/mdb/test MDBUnitTestCase.java
  Log:
  Now catching deployment exceptions in setUp() and throwing it in
  testServerFound().
  This way, a deployment failure does not result in an empty .xml file,
  making the test case being forgotten in the final report.
  
  Also added testServerFound() to the MDB testcase.
  
  Revision  ChangesPath
  1.6   +2 -1  jbosstest/src/main/org/jboss/test/mdb/test/MDBUnitTestCase.java
  
  Index: MDBUnitTestCase.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/mdb/test/MDBUnitTestCase.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- MDBUnitTestCase.java  2001/09/25 03:34:46 1.5
  +++ MDBUnitTestCase.java  2001/10/20 22:25:58 1.6
  @@ -51,7 +51,7 @@
* @author  a href=mailto:[EMAIL PROTECTED];Peter Antman/a
* @author  a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author  a href=mailto:[EMAIL PROTECTED];David Jencks/a
  - * @version pre$Revision: 1.5 $/pre
  + * @version pre$Revision: 1.6 $/pre
*/
   public class MDBUnitTestCase
  extends JBossTestCase
  @@ -190,6 +190,7 @@
  public static Test suite() throws Exception
  {
 TestSuite suite = new TestSuite();
  +  suite.addTest(new MDBUnitTestCase(testServerFound,));
 suite.addTest(new MDBUnitTestCase(testObjectMessage,));
 suite.addTest(new MDBUnitTestCase(testQueue,queue/testQueue));
 suite.addTest(new MDBUnitTestCase(testTopic,topic/testTopic));
  
  
  

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



[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test JBossTestCase.java

2001-10-20 Thread Ole Husgaard

  User: sparre  
  Date: 01/10/20 15:25:58

  Modified:src/main/org/jboss/test JBossTestCase.java
  Log:
  Now catching deployment exceptions in setUp() and throwing it in
  testServerFound().
  This way, a deployment failure does not result in an empty .xml file,
  making the test case being forgotten in the final report.
  
  Also added testServerFound() to the MDB testcase.
  
  Revision  ChangesPath
  1.8   +18 -3 jbosstest/src/main/org/jboss/test/JBossTestCase.java
  
  Index: JBossTestCase.java
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/JBossTestCase.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JBossTestCase.java2001/10/08 16:53:00 1.7
  +++ JBossTestCase.java2001/10/20 22:25:58 1.8
  @@ -42,11 +42,16 @@
* ../lib).
*
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
  - * @version   $Revision: 1.7 $
  + * @version   $Revision: 1.8 $
*/
   public class JBossTestCase
  extends TestCase
   {
  +   /**
  +*  Saved exception from deployment.
  +*  Will be thrown from {@link #testServerFound}, if not codenull/code.
  +*/
  +   private static Exception deploymentException = null;
   
  private JBossTestServices delegate;
   
  @@ -70,11 +75,15 @@
  /**
   * This just checks the server is there... so you should get at least one
   * success!
  +* Also checks if an exception occurred during deployment, and throws
  +* any such exception from here.
   *
   * @exception Exception  Description of Exception
   */
  public void testServerFound() throws Exception
  {
  +  if (deploymentException != null)
  + throw deploymentException;
 assertTrue(Server was not found, getServer() != null);
  }
   
  @@ -257,8 +266,14 @@
   
protected void setUp() throws Exception
{
  -this.deployJ2ee(jarName);
  -this.getLog().debug(deployed package:  + jarName);
  +deploymentException = null;
  +try {
  +   this.deployJ2ee(jarName);
  +   this.getLog().debug(deployed package:  + jarName);
  +} catch (Exception ex) {
  +   // Throw this in testServerFound() instead.
  +   deploymentException = ex;
  +}
}
   
protected void tearDown() throws Exception
  
  
  

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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Ole Husgaard

Scott M Stark wrote:
 A non-stress target already exists and is called tests-unit. It does not
 include any of the stress testing and runs in 5.5 minutes on a PIII 850MHz
 single processor box:
 
 testsuite 1729./build.sh tests-unit

Ahh, I didn't notice that.
Much faster than the complete testsuite.

Maybe, if this is what we want committers to run before
committing, we should add a target in the RH main build
file that calls this target - like we have now with the
complete test suite target?
That would make it even easier to run the most basic
tests, thus raising chances that these tests are actually
run before new code is committed.


Best Regards,

Ole Husgaard.

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



Re: [JBoss-dev] FAQ

2001-10-20 Thread Luke Taylor



marc fleury wrote:
 
 We have one under the developer links, I think it could go back under the
 user links.
 
 One of the problems is that few people maintain it so it tends to get out of
 whack.
 
 If you have some time you could prune it and I will gladly reinstate it.
 
 marcf
 

I'd be happy to contribute to this. If you like, I could have a go at
putting together a more datailed FAQ, based on the current one. It
would be a useful way of gathering together what I've learned about
JBoss so far, and also help to consolidate other stuff (I'm generally
very lazy about learning stuff unless I have a specific task in hand).

I think numbering (e.g. docbook generated) would be a good start in
terms of maintenance - at least then someone can register the fact tha
FAQ x.y.z is no longer accurate...

Luke.

-- 
 Luke Taylor.  Monkey Machine Ltd.
 PGP Key ID: 0x57E9523Chttp://www.mkeym.com

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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Scott M Stark

I added a run-basic-testsuite to the main build.xml file that invokes
the tests-unit target in the testsuite module.

- Original Message - 
From: Ole Husgaard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, October 20, 2001 3:51 PM
Subject: Re: [JBoss-dev] Please run the test suite before committing.



 Maybe, if this is what we want committers to run before
 committing, we should add a target in the RH main build
 file that calls this target - like we have now with the
 complete test suite target?
 That would make it even easier to run the most basic
 tests, thus raising chances that these tests are actually
 run before new code is committed.
 



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



[JBoss-dev] CVS update: build/jboss build.xml

2001-10-20 Thread Scott M Stark

  User: starksm 
  Date: 01/10/20 16:52:52

  Modified:jbossbuild.xml
  Log:
  Add a run-basic-testsuite to the main build.xml file that invokes
  the tests-unit target in the testsuite module. This test should be run
  prior to any commits to ensure a minimum compatibility level with the
  existing code base.
  
  Revision  ChangesPath
  1.42  +17 -1 build/jboss/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/build/jboss/build.xml,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- build.xml 2001/10/20 04:24:23 1.41
  +++ build.xml 2001/10/20 23:52:52 1.42
  @@ -10,7 +10,7 @@
   !----
   !-- == --
   
  -!-- $Id: build.xml,v 1.41 2001/10/20 04:24:23 schaefera Exp $ --
  +!-- $Id: build.xml,v 1.42 2001/10/20 23:52:52 starksm Exp $ --
   
   project default=main name=JBoss/Build
   
  @@ -1501,6 +1501,22 @@
 !-- == --
   
 target name=testsuite depends=run-testsuite/
  +
  +  !-- Invoke the 'tests-unit' on the 'testsuite' module. This must
  +be run prior to commiting any changes to ensure that your changes
  +don't cause grief to other developers.
  +  --
  +  target name=run-basic-testsuite depends=init
  +  description=Execute the testsuite.
  +execmodules target=tests-unit modules=testsuite
  + root=${project.root}/${module}
  + skipmissing=${executemodules.skipmissing}
  +  before target=${target}-${module}-prepare/
  +  header message=${executemodules.header}/
  +  footer message=${executemodules.footer}/
  +  after target=${target}-${module}/
  +/execmodules
  +  /target
   
 !-- Invoke the 'tests' on the 'testsuite' module --
 target name=run-testsuite depends=init
  
  
  

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



Re: [JBoss-dev] FAQ

2001-10-20 Thread David Jencks

How about a wiki? It seems to me that this might be a better solution for
such continually changing info as jboss FAQ/howto.

One possibility is very quick wiki, that I just found (haven't tried it
yet)
http://sourceforge.net/projects/veryquickwiki/

It claims to be a drop- in war in any j2ee web container.


david jencks

On 2001.10.20 18:57:50 -0400 Luke Taylor wrote:
 
 
 marc fleury wrote:
  
  We have one under the developer links, I think it could go back under
 the
  user links.
  
  One of the problems is that few people maintain it so it tends to get
 out of
  whack.
  
  If you have some time you could prune it and I will gladly reinstate
 it.
  
  marcf
  
 
 I'd be happy to contribute to this. If you like, I could have a go at
 putting together a more datailed FAQ, based on the current one. It
 would be a useful way of gathering together what I've learned about
 JBoss so far, and also help to consolidate other stuff (I'm generally
 very lazy about learning stuff unless I have a specific task in hand).
 
 I think numbering (e.g. docbook generated) would be a good start in
 terms of maintenance - at least then someone can register the fact tha
 FAQ x.y.z is no longer accurate...
 
 Luke.
 
 -- 
  Luke Taylor.  Monkey Machine Ltd.
  PGP Key ID: 0x57E9523Chttp://www.mkeym.com
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



[JBoss-dev] [ jboss-Patches-473280 ] database generated identity value pk's

2001-10-20 Thread noreply

Patches item #473280, was opened at 2001-10-20 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376687aid=473280group_id=22866

Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerolf Scherr (gscherr)
Assigned to: Nobody/Anonymous (nobody)
Summary: database generated identity value pk's

Initial Comment:
Hi everybody!

I have added support for database generated identity 
value primary keys to jaws.

This is activated by setting the pk-identity flag in 
jaws.xml to true and works with MS SQLSERVER numeric 
primary keys. The pk is created by the database at 
insert time and read back. (Tested with Version 7 and 
the inet driver). 

The SQL Syntax is:

create table test (testid integer identity not null 
primary key, testvalue varchar(30))
insert into  test(testvalue) values('test') ; select 
@@identity

I have attached a file with the patched source (based 
on the 2.4 source) and an updated dtd.

gerolf.

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376687aid=473280group_id=22866

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



Re: [JBoss-dev] FAQ

2001-10-20 Thread Peter Fagerlund

on 1-10-21 02.34, David Jencks at [EMAIL PROTECTED] wrote:

 How about a wiki?

Yes or get these linguistic kids to play ... becouse here is content ...

/peter_f


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



RE: [JBoss-dev] FAQ

2001-10-20 Thread marc fleury

Interesting.

I just played with the phpWiki stuff and I guess it is worth a try.

Can you try running it on Jetty and then ask andreas to put it somewhere in
the website

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Jencks
|Sent: Saturday, October 20, 2001 8:35 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] FAQ
|
|
|How about a wiki? It seems to me that this might be a better solution for
|such continually changing info as jboss FAQ/howto.
|
|One possibility is very quick wiki, that I just found (haven't tried it
|yet)
|http://sourceforge.net/projects/veryquickwiki/
|
|It claims to be a drop- in war in any j2ee web container.
|
|
|david jencks
|
|On 2001.10.20 18:57:50 -0400 Luke Taylor wrote:
|
|
| marc fleury wrote:
| 
|  We have one under the developer links, I think it could go back under
| the
|  user links.
| 
|  One of the problems is that few people maintain it so it tends to get
| out of
|  whack.
| 
|  If you have some time you could prune it and I will gladly reinstate
| it.
| 
|  marcf
| 
|
| I'd be happy to contribute to this. If you like, I could have a go at
| putting together a more datailed FAQ, based on the current one. It
| would be a useful way of gathering together what I've learned about
| JBoss so far, and also help to consolidate other stuff (I'm generally
| very lazy about learning stuff unless I have a specific task in hand).
|
| I think numbering (e.g. docbook generated) would be a good start in
| terms of maintenance - at least then someone can register the fact tha
| FAQ x.y.z is no longer accurate...
|
| Luke.
|
| --
|  Luke Taylor.  Monkey Machine Ltd.
|  PGP Key ID: 0x57E9523Chttp://www.mkeym.com
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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



RE: [JBoss-dev] FAQ

2001-10-20 Thread marc fleury

|Yes or get these linguistic kids to play ... becouse here is content ...

Look who is talking ;-)

There used to be this Holger Baxman character who would just babelfish
his german posts about 2 years ago, and then he would talk about impossible
stuff like abstract metadata repositories in broken machine translation.

marcf

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


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



Re: [JBoss-dev] FAQ

2001-10-20 Thread Peter Fagerlund

on 1-10-21 03.57, marc fleury at [EMAIL PROTECTED] wrote:

 abstract metadata repositories in broken machine translation.

http://193.14.119.195/ljud\sexydollar.mp3


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



[JBoss-dev] Automated JBoss Testsuite Results

2001-10-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   140



Successful tests:  129

Errors:5

Failures:  6





[time of test: 21 October 2001 3:16 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.vm.version: 1.3.0]
[java.vm.name: Classic VM]
[java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)]
[os.name: Linux]
[os.arch: x86]
[os.version: 2.4.9-6]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



RE: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Dain Sundstrom

Maybe I am a complete idiot, but what should I see if the test is
successful?

As a policy, should some one only check-in if the change does not increase
the number of failures / errors? 

Dain

 -Original Message-
 From: Scott M Stark [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, October 20, 2001 6:58 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Please run the test suite before committing.
 
 
 I added a run-basic-testsuite to the main build.xml file that invokes
 the tests-unit target in the testsuite module.
 
 - Original Message - 
 From: Ole Husgaard [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, October 20, 2001 3:51 PM
 Subject: Re: [JBoss-dev] Please run the test suite before committing.
 
 
 
  Maybe, if this is what we want committers to run before
  committing, we should add a target in the RH main build
  file that calls this target - like we have now with the
  complete test suite target?
  That would make it even easier to run the most basic
  tests, thus raising chances that these tests are actually
  run before new code is committed.
  
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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



[JBoss-dev] Missplaced java files

2001-10-20 Thread Hiram Chirino

Hi guys..

FarmAutoDeployer.java and FarmAutoDeployerMBean.java is in the 
org/jboss/system path but it's packages are org.jboss.deployment.

Is it ok if I move them to the org/jboss/deployment dir???

Is there a plan for the tests in test/jboss??  Should they be getting moved 
into the test suite??

Regards,
Hiram



_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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



[JBoss-dev] Automated JBoss Testsuite Results

2001-10-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   140



Successful tests:  131

Errors:4

Failures:  5





[time of test: 21 October 2001 4:8 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-FCS]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-6]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge NewQueuedPessimisticEJBLock.java NonentrantMessage.java

2001-10-20 Thread Dain Sundstrom

  User: dsundstrom
  Date: 01/10/20 20:12:59

  Added:   src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
NewQueuedPessimisticEJBLock.java
NonentrantMessage.java
  Log:
  These classes demonstrate a strategy for marking some method invocations
  through the interceptor chain as not entrant.  Non-entrant invocations
  are used in the cmp 2.0 relationship code.  If this strategy is accecpted
  these classes will most like be moved and / or integated into the locking
  code.
  
  Revision  ChangesPath
  1.1  
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/NewQueuedPessimisticEJBLock.java
  
  Index: NewQueuedPessimisticEJBLock.java
  ===
  /*
   * JBoss, the OpenSource J2EE webOS
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  package org.jboss.ejb.plugins.cmp.jdbc.bridge;
  
  import org.jboss.ejb.MethodInvocation;
  import org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock;
  
  /**
   * A example of testing the method to see if is not supposed
   * to be entrant.
   */
  public class NewQueuedPessimisticEJBLock
 extends QueuedPessimisticEJBLock
  {
 protected boolean isCallAllowed(MethodInvocation mi)
 {
return super.isCallAllowed(mi) ||
  NonentrantMessage.class.isAssignableFrom(
mi.getMethod().getDeclaringClass());
 }
  }
  
  
  
  1.1  
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/NonentrantMessage.java
  
  Index: NonentrantMessage.java
  ===
  /*
   * JBoss, the OpenSource J2EE webOS
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  package org.jboss.ejb.plugins.cmp.jdbc.bridge;
  
  /**
   * This interface is used to mark the methods of a subclass as a
   * non-entrant ejb invocation. The bean lock will let a call through
   * if the method is defined on a sub-interface of inplementatior of
   * this interface.
   *
   * @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
   * @version $Revision: 1.1 $
   */
  public interface NonentrantMessage {
  }
  
  
  

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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/adaptor/xml XMLTestService.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 20:17:01

  Modified:src/main/org/jboss/jmx/adaptor/xml XMLTestService.java
  Log:
  Removed one of the deprecation warnings
  
  Revision  ChangesPath
  1.3   +4 -4  jboss/src/main/org/jboss/jmx/adaptor/xml/XMLTestService.java
  
  Index: XMLTestService.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/adaptor/xml/XMLTestService.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- XMLTestService.java   2001/09/12 02:10:23 1.2
  +++ XMLTestService.java   2001/10/21 03:17:00 1.3
  @@ -6,7 +6,7 @@
   */
   package org.jboss.jmx.adaptor.xml;
   
  -import java.io.StringBufferInputStream;
  +import java.io.ByteArrayInputStream;
   import java.util.Iterator;
   
   import javax.management.MBeanServer;
  @@ -24,7 +24,7 @@
   *
   * @author Andreas Schaefer ([EMAIL PROTECTED])
   * @created June 22, 2001
  -* @version $Revision: 1.2 $
  +* @version $Revision: 1.3 $
   */
   public class XMLTestService
 extends ServiceMBeanSupport
  @@ -74,7 +74,7 @@
 System.out.println( Got object name:  + lName );
 // Create Test XML Document
 Document lTest = 
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(
  -new StringBufferInputStream(
  +new ByteArrayInputStream(new String(
 jmx +
 invoke operation=\stop\object-name 
name=\:service=Scheduler\//invoke +
 create-mbean code=\org.jboss.util.Scheduler\ +
  @@ -94,7 +94,7 @@
   attribute name=\PeriodTime\5000/attribute +
 /set-attribute +
 /jmx
  -)
  +  ).getBytes())
 );
 System.out.println( Call invokeXML with:  + lTest );
 getServer().invoke(
  
  
  

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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge CMRMessage.java

2001-10-20 Thread Dain Sundstrom

  User: dsundstrom
  Date: 01/10/20 20:17:10

  Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
CMRMessage.java
  Log:
  Messages are now marked as non-entrant.
  
  Revision  ChangesPath
  1.4   +2 -2  
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/CMRMessage.java
  
  Index: CMRMessage.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/CMRMessage.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CMRMessage.java   2001/09/01 22:03:16 1.3
  +++ CMRMessage.java   2001/10/21 03:17:10 1.4
  @@ -15,9 +15,9 @@
* JDBCRelationInterceptor.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*/
  -public interface CMRMessage {
  +public interface CMRMessage extends NonentrantMessage {
  public Object getRelatedId(EntityEnterpriseContext myCtx, JDBCCMRFieldBridge 
cmrField);
  public void addRelation(EntityEnterpriseContext myCtx, Object relatedId);
  public void removeRelation(EntityEnterpriseContext myCtx, Object relatedId);
  
  
  

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



[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjboss.xml

2001-10-20 Thread Dain Sundstrom

  User: dsundstrom
  Date: 01/10/20 20:21:03

  Modified:src/etc/conf/default standardjboss.xml
  Log:
  Changed cmp 2.0 beans to use the modified queued pessimistic lock, which
  handles non-entrant method invocations.
  
  Revision  ChangesPath
  1.23  +3 -2  jboss/src/etc/conf/default/standardjboss.xml
  
  Index: standardjboss.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- standardjboss.xml 2001/10/20 22:09:35 1.22
  +++ standardjboss.xml 2001/10/21 03:21:03 1.23
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: standardjboss.xml,v 1.22 2001/10/20 22:09:35 patriot1burke Exp $ --
  +!-- $Id: standardjboss.xml,v 1.23 2001/10/21 03:21:03 dsundstrom Exp $ --
   
   jboss
  enforce-ejb-restrictionsfalse/enforce-ejb-restrictions
  @@ -32,7 +32,8 @@
 instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache
 
persistence-managerorg.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager/persistence-manager
 transaction-managerorg.jboss.tm.TxManager/transaction-manager
  -  
locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy
  +!-- 
locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy 
--
  +
locking-policyorg.jboss.ejb.plugins.cmp.jdbc.bridge.NewQueuedPessimisticEJBLock/locking-policy
 container-invoker-conf
OptimizedTrue/Optimized
RMIObjectPort/RMIObjectPort
  
  
  

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



Re: [JBoss-dev] Missplaced java files

2001-10-20 Thread David Jencks

On 2001.10.20 22:54:19 -0400 Hiram Chirino wrote:
 Hi guys..
 
 FarmAutoDeployer.java and FarmAutoDeployerMBean.java is in the 
 org/jboss/system path but it's packages are org.jboss.deployment.
 
 Is it ok if I move them to the org/jboss/deployment dir???

Sounds good to me, but I guess Andy knows for sure.
 
 Is there a plan for the tests in test/jboss??  Should they be getting
 moved 
 into the test suite??

I believe these are very old and obsolete.  Look carefully to see if they
have anything to do with the current code before moving them -- also you'd
get to turn them into junit tests I think.  Doing something with them so
they move or disappear would be great.

david jencks
 
 Regards,
 Hiram
 
 
 
 _
 Get your FREE download of MSN Explorer at
 http://explorer.msn.com/intl.asp
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



Re: [JBoss-dev] Clustering is available for use

2001-10-20 Thread Rick Gibbs



This is amazing, you guys have been rockin 
the house, I can't wait to try this out.

I was wondering what the easiest way to 
define custom load balancing polices would be. We have an application 
which hosts multiple clients and we would like to develop a policy that ensures 
all requests for a particular client goes to the same server for each request so 
the their data is cached in one place. I think it would be farily easy to 
implement on top of a RoundRobin policy that exists just not really sure where 
to start. Any pointers?

BTW: We have been running jboss for 5 
months now and host roughly 200 clients and the numbers are growing 
weekly!! Again, you guys rock!!

Thanks

 Rick


___
Rick Gibbs
Dealer.com (formerly 
Earthcars.com)
[EMAIL PROTECTED]

  - Original Message - 
  From: 
  Bill 
  Burke 
  To: Jboss-User@Lists. 
  Sourceforge. Net ; Jboss-Development@Lists. 
  Sourceforge. Net 
  Sent: Saturday, October 20, 2001 6:20 
  PM
  Subject: [JBoss-dev] Clustering is 
  available for use
  
  Hi 
  all,
  
  Sacha Labourey and 
  I would like to announce the availability of new JBoss clustering features in 
  RabbitHole-3.0 (the mainline). There is still a lot of testing to be 
  done so this is really BETA code. If you have any questions, pop either 
  one of us an email on the jboss-dev list. I'll be in Las Vegas next week 
  so hopefully Sacha can answer all questions for now. The below HOWTO 
  will be merged into documentation eventually when one of us has 
  time.
  
  Regards,
  
  Bill
  
  
  Features
  
You must have JDK 
1.3.x Will not work with JDK earlier than this. 
Sorry 
Built on top of 
JavaGroups. http://www.javagroups.com 

Automatic group 
discovery. Cluster nodes can automatically find eachother(BUT THEY 
DON"T SHARE CONFIGURATIONS!) 
A general 
framework wrapped around JavaGroups that provides group communications thru 
RPCs, a state transfer protocol, and membership change 
notification 
Cluster-wide JNDI 
(a.k.a HA-JNDI) 
Failover for 
HA-JNDI, Stateless Session Beans, Entity Beans, and also any RMI object you 
want to replicate 
method calls are 
collocated if possible even if the proxy is serialized to another 
node. 
SLSB, HA-JNDI, 
and Home calls are load-balanced Round Robin. Entity Bean calls are 
NOT load-balanced.
  Quick 
  Start
  
Get latest and 
build from CVS mainline (RH 3.0) (Don't ask me how to do 
this!) 
Copy 
.../jboss-all/cluster/etc/cluster-service.xml to JBoss's deploy/ 
directory 
Edit any SLSB or 
EntityBean's "jboss.xml" to put in clustered flag (see 
.../jboss-all/cluster/etc/jboss.xml for example
  
i.e.

jboss 
securefalse/secure
 
enterprise-beans 
session 
ejb-namenextgen.StatelessSession/ejb-name 
jndi-namenextgen.StatelessSession/jndi-nameclusteredTrue/clustered 
/session 
entity 
ejb-namenextgen.EnterpriseEntity/ejb-name 
jndi-namenextgen.EnterpriseEntity/jndi-name 
clusteredTrue/clustered 
/entity/enterprise-beans

/jboss
  

To use HA-JNDI you must 
have a list of cluster nodes in the provider URL list separated by commas, 
HA-JNDI runs off of port 1100 by default:
  
java.naming.provider.url=server1:1100,server2:1100,server3:1100

  

HA-JNDI is NOT a required service. You can 
connect to any cluster node's local JNDI.
  Problems 
  you may encounter
  
Only JDK 1.3.x is 
supported. It will not work with an earlier JDK. 
Do NOT use 
commit-option 'A' with Entity Beans!!! 
If you want to 
synchronize Entity Beans across the cluster use select-for-update 
Unfortunately this feature may only work with Oracle :-(. We will be 
expanding this feature later on. 
Clustered beans 
do NOT support Transaction Propagation unless the method call is 
collocated. 
We think we've 
fixed this problem, but if you bring 2 clustered nodes up at the same time 
and have problems, start them completely one at a time. 
MERGEing doesn't 
work well yet. What is Merging? Let's say a part of the cluster 
becomes separated from the group because of a bad network switch or 
something. These orphaned nodes don't die, but are just cut off from 
the network. When these orphaned nodes are hooked up to the network 
again, JBoss Clustering(through JavaGroups) will merge the orphaned nodes 
into the group. This does not work well all the 
time.
  
  
  Advanced 
  Setup
  
  How clustering is configured will expand over time, 
  but here's what can be configured right now.
  
  Advanced 
  Cluster Configuration
  One JBoss instance 
  can belong to multiple different clusters.(Beans can only belong to one 
  cluster though!) You can do this by plopping another mbean into jboss 
  and give a name for the specific cluster. 
  
  

RE: [JBoss-dev] Clustering is available for use

2001-10-20 Thread marc fleury



How about a nice little quote/reference 
Rick?

marcf

BTW: We have been running jboss for 5 
months now and host roughly 200 clients and the numbers are growing 
weekly!! Again, you guys rock!!

  
  Thanks
  
   Rick
  
  
  ___
  Rick Gibbs
  Dealer.com (formerly 
  Earthcars.com)
  [EMAIL PROTECTED]
  
- Original Message - 
From: 
Bill 
Burke 
To: Jboss-User@Lists. 
Sourceforge. Net ; Jboss-Development@Lists. 
Sourceforge. Net 
Sent: Saturday, October 20, 2001 6:20 
PM
Subject: [JBoss-dev] Clustering is 
available for use

Hi 
all,

Sacha Labourey 
and I would like to announce the availability of new JBoss clustering 
features in RabbitHole-3.0 (the mainline). There is still a lot of 
testing to be done so this is really BETA code. If you have any 
questions, pop either one of us an email on the jboss-dev list. I'll 
be in Las Vegas next week so hopefully Sacha can answer all questions for 
now. The below HOWTO will be merged into documentation eventually when 
one of us has time.

Regards,

Bill


Features

  You must have 
  JDK 1.3.x Will not work with JDK earlier than this. 
  Sorry 
  Built on top of 
  JavaGroups. http://www.javagroups.com 

  Automatic group 
  discovery. Cluster nodes can automatically find eachother(BUT THEY 
  DON"T SHARE CONFIGURATIONS!) 
  A general 
  framework wrapped around JavaGroups that provides group communications 
  thru RPCs, a state transfer protocol, and membership change 
  notification 
  Cluster-wide 
  JNDI (a.k.a HA-JNDI) 
  Failover for 
  HA-JNDI, Stateless Session Beans, Entity Beans, and also any RMI object 
  you want to replicate 
  method calls 
  are collocated if possible even if the proxy is serialized to another 
  node. 
  SLSB, HA-JNDI, 
  and Home calls are load-balanced Round Robin. Entity Bean calls are 
  NOT load-balanced.
Quick 
Start

  Get latest and 
  build from CVS mainline (RH 3.0) (Don't ask me how to do 
  this!) 
  Copy 
  .../jboss-all/cluster/etc/cluster-service.xml to JBoss's deploy/ 
  directory 
  Edit any SLSB 
  or EntityBean's "jboss.xml" to put in clustered flag (see 
  .../jboss-all/cluster/etc/jboss.xml for example

  i.e.
  
  jboss 
  securefalse/secure
   
  enterprise-beans 
  session 
  ejb-namenextgen.StatelessSession/ejb-name 
  jndi-namenextgen.StatelessSession/jndi-nameclusteredTrue/clustered 
  /session 
  entity 
  ejb-namenextgen.EnterpriseEntity/ejb-name 
  jndi-namenextgen.EnterpriseEntity/jndi-name 
  clusteredTrue/clustered 
  /entity/enterprise-beans
  
  /jboss

  
  To use HA-JNDI you must 
  have a list of cluster nodes in the provider URL list separated by commas, 
  HA-JNDI runs off of port 1100 by default:

  java.naming.provider.url=server1:1100,server2:1100,server3:1100
  

  
  HA-JNDI is NOT a required service. You can 
  connect to any cluster node's local JNDI.
Problems 
you may encounter

  Only JDK 1.3.x 
  is supported. It will not work with an earlier JDK. 
  Do NOT use 
  commit-option 'A' with Entity Beans!!! 
  If you want to 
  synchronize Entity Beans across the cluster use select-for-update 
  Unfortunately this feature may only work with Oracle :-(. We will be 
  expanding this feature later on. 
  Clustered beans 
  do NOT support Transaction Propagation unless the method call is 
  collocated. 
  We think we've 
  fixed this problem, but if you bring 2 clustered nodes up at the same time 
  and have problems, start them completely one at a time. 
  MERGEing 
  doesn't work well yet. What is Merging? Let's say a part of 
  the cluster becomes separated from the group because of a bad network 
  switch or something. These orphaned nodes don't die, but are just 
  cut off from the network. When these orphaned nodes are hooked up to 
  the network again, JBoss Clustering(through JavaGroups) will merge the 
  orphaned nodes into the group. This does not work well all the 
  time.


Advanced 
Setup

How clustering is configured will expand over time, 
but here's what can be configured right now.

Advanced 
Cluster Configuration
One JBoss 
instance can belong to multiple different clusters.(Beans can only belong to 
one cluster though!) You can do this by plopping another mbean into 
jboss and give a name for the specific cluster. 

Cluster 
configuration variables(these can be defined as mbean properties in 
cluster-service.xml for example):
PartitionName: Name the cluster 
partition. The default is 

[JBoss-dev] Automated JBoss Testsuite Results

2001-10-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   130



Successful tests:  121

Errors:4

Failures:  5





[time of test: 21 October 2001 5:29 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-FCS]
[java.vm.name: Classic VM]
[java.vm.info: green threads, nojit]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-6]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



[JBoss-dev] Automated JBoss Testsuite Results

2001-10-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   140



Successful tests:  131

Errors:4

Failures:  5





[time of test: 21 October 2001 6:29 GMT]
[java.version: 1.3.1]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1-b24]
[java.vm.name: Java HotSpot(TM) Server VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-6]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



Re: [JBoss-dev] Please run the test suite before committing.

2001-10-20 Thread Scott Stark

In the jboss-all/testsuite/output/report directory will be an html 
directory and a
text directory that contain the unit test summaries. The 
text/TESTS-TestSuites.txt
file is what is mailed to the list and contains the number of tests run, 
successful
tests, errors and failures. The html/index.html file contains a more 
detailed summary
as well as all unit test results.

In general you should not be checking in changes that introduce new 
errors. If there
are errors you can determine if they have been there by checking the 
previous test
results that Chris is maintaining on this site:  http://lubega.com


Scott Stark
Chief Technology Officer
JBoss Group, LLC


On Saturday, October 20, 2001, at 07:40 PM, Dain Sundstrom wrote:

 Maybe I am a complete idiot, but what should I see if the test is
 successful?

 As a policy, should some one only check-in if the change does not 
 increase
 the number of failures / errors?

 Dain

 -Original Message-
 From: Scott M Stark [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, October 20, 2001 6:58 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Please run the test suite before committing.


 I added a run-basic-testsuite to the main build.xml file that invokes
 the tests-unit target in the testsuite module.

 - Original Message -
 From: Ole Husgaard [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, October 20, 2001 3:51 PM
 Subject: Re: [JBoss-dev] Please run the test suite before committing.




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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq GenericConnectionFactory.java SpyConnectionFactory.java SpyXAConnectionFactory.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:12

  Modified:src/main/org/jboss/mq GenericConnectionFactory.java
SpyConnectionFactory.java
SpyXAConnectionFactory.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.4   +5 -11 jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java
  
  Index: GenericConnectionFactory.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- GenericConnectionFactory.java 2001/09/27 03:27:42 1.3
  +++ GenericConnectionFactory.java 2001/10/21 05:38:12 1.4
  @@ -19,9 +19,10 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.3 $
  + * @version$Revision: 1.4 $
*/
   public class GenericConnectionFactory implements java.io.Serializable {
  +   static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance( 
GenericConnectionFactory.class );
   
  // An instance of the ServerIL, once it is setup, we make clones every
  // time a new connection is needed.
  @@ -31,13 +32,6 @@
  // And to setup a connection from the server to the client.
  private Properties connectionProperties;
   
  -   // These are the keys we look for in the connection properties
  -   public final static String SERVER_IL_FACTORY_KEY = ServerILFactory;
  -   public final static String CLIENT_IL_SERVICE_KEY = ClientILService;
  -   public final static String PING_PERIOD_KEY = PingPeriod;
  -
  -   static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance( 
GenericConnectionFactory.class );
  -
   
  /**
   *  The constructor takes a ServerIL and the Connection Properties
  @@ -66,11 +60,11 @@
  public ClientILService createClientILService( Connection connection )
 throws Exception {
 // This is a good time to setup the PingPeriod
  -  String pingPeriod = connectionProperties.getProperty( PING_PERIOD_KEY, 
+connection.pingPeriod ); 
  +  String pingPeriod = connectionProperties.getProperty( 
ServerILFactory.PING_PERIOD_KEY, +connection.pingPeriod ); 
 connection.pingPeriod = Long.parseLong(pingPeriod);
 
 // Setup the client connection.
  -  String clientILServiceCN = connectionProperties.getProperty( 
CLIENT_IL_SERVICE_KEY );
  +  String clientILServiceCN = connectionProperties.getProperty( 
ServerILFactory.CLIENT_IL_SERVICE_KEY );
 ClientILService service = ( ClientILService )Class.forName( clientILServiceCN 
).newInstance();
 service.init( connection, connectionProperties );
 return service;
  @@ -91,7 +85,7 @@
// A ServerILFactory
if ( server == null ) {
   
  -String className = connectionProperties.getProperty( 
SERVER_IL_FACTORY_KEY );
  +String className = connectionProperties.getProperty( 
ServerILFactory.SERVER_IL_FACTORY_KEY );
   ServerILFactory factory = ( ServerILFactory )Class.forName( className 
).newInstance();
   factory.init( connectionProperties );
   
  
  
  
  1.3   +5 -2  jbossmq/src/main/org/jboss/mq/SpyConnectionFactory.java
  
  Index: SpyConnectionFactory.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyConnectionFactory.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SpyConnectionFactory.java 2001/08/17 03:04:01 1.2
  +++ SpyConnectionFactory.java 2001/10/21 05:38:12 1.3
  @@ -25,7 +25,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public class SpyConnectionFactory implements java.io.Serializable, 
javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory, 
javax.naming.Referenceable {
  // Attributes 
  @@ -35,9 +35,12 @@
  static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance( 
SpyConnectionFactory.class );
   
  // Constructor ---
  -
  public SpyConnectionFactory( GenericConnectionFactory factory ) {
 this.factory = factory;
  +   }
  +   
  +   public SpyConnectionFactory( Properties config ) {
  +  this.factory = new GenericConnectionFactory(null, config);
  }
   
  /**
  
  
  
  1.3   +5 -1  jbossmq/src/main/org/jboss/mq/SpyXAConnectionFactory.java
  
  Index: SpyXAConnectionFactory.java
 

[JBoss-dev] CVS update: build/jboss build.xml

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:12

  Modified:jbossbuild.xml
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.43  +4 -3  build/jboss/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/build/jboss/build.xml,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- build.xml 2001/10/20 23:52:52 1.42
  +++ build.xml 2001/10/21 05:38:12 1.43
  @@ -10,7 +10,7 @@
   !----
   !-- == --
   
  -!-- $Id: build.xml,v 1.42 2001/10/20 23:52:52 starksm Exp $ --
  +!-- $Id: build.xml,v 1.43 2001/10/21 05:38:12 chirino Exp $ --
   
   project default=main name=JBoss/Build
   
  @@ -1581,8 +1581,9 @@
 /target
   
 target name=run-jboss-win32 depends=init if=run.jboss.win32
  -exec executable=${project.release}/${release.id}/bin/run.bat
  -   dir=${project.release}/${release.id}
  +echo message=${module.output}/${release.id}/
  +exec executable=${module.output}/${release.id}/bin/run.bat
  +   dir=${module.output}/${release.id}/bin
 output=${basedir}/run.log
  newenvironment=true
 arg line=${run.jboss.flags}/
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/etc/conf/default jbossmq-service.xml

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:12

  Modified:src/etc/conf/default jbossmq-service.xml
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.6   +3 -3  jbossmq/src/etc/conf/default/jbossmq-service.xml
  
  Index: jbossmq-service.xml
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/etc/conf/default/jbossmq-service.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jbossmq-service.xml   2001/09/27 04:21:25 1.5
  +++ jbossmq-service.xml   2001/10/21 05:38:12 1.6
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: jbossmq-service.xml,v 1.5 2001/09/27 04:21:25 chirino Exp $ --
  +!-- $Id: jbossmq-service.xml,v 1.6 2001/10/21 05:38:12 chirino Exp $ --
   
   !-- 
  |  This is where you can add and configure your MBeans.
  @@ -73,7 +73,7 @@
 name=JBossMQ:service=InvocationLayer,type=OIL
   attribute name=ConnectionFactoryJNDIRefConnectionFactory/attribute
   attribute name=XAConnectionFactoryJNDIRefXAConnectionFactory/attribute
  -attribute name=ServerBindPort0/attribute
  +attribute name=ServerBindPort8090/attribute
   attribute name=PingPeriod6/attribute
 /mbean
   
  @@ -81,7 +81,7 @@
 name=JBossMQ:service=InvocationLayer,type=UIL
   attribute name=ConnectionFactoryJNDIRefUILConnectionFactory/attribute
   attribute name=XAConnectionFactoryJNDIRefUILXAConnectionFactory/attribute
  -attribute name=ServerBindPort0/attribute
  +attribute name=ServerBindPort8091/attribute
   attribute name=PingPeriod6/attribute
 /mbean
   
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILServerILFactory.java UILServerILService.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:13

  Modified:src/main/org/jboss/mq/il/uil UILServerILService.java
  Added:   src/main/org/jboss/mq/il/uil UILServerILFactory.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.12  +3 -2  jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java
  
  Index: UILServerILService.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- UILServerILService.java   2001/10/03 02:36:25 1.11
  +++ UILServerILService.java   2001/10/21 05:38:13 1.12
  @@ -40,12 +40,13 @@
   import org.jboss.mq.il.ServerILJMXService;
   import org.jboss.mq.il.uil.multiplexor.*;
   import org.jboss.mq.server.JMSServer;
  +import org.jboss.mq.il.ServerILFactory;
   
   /**
* Implements the ServerILJMXService which is used to manage the JVM IL.
*
* @authorHiram Chirino ([EMAIL PROTECTED])
  - * @version   $Revision: 1.11 $
  + * @version   $Revision: 1.12 $
*/
   public class UILServerILService extends org.jboss.mq.il.ServerILJMXService 
implements Runnable, UILServerILServiceMBean
   {
  @@ -99,7 +100,7 @@
  public java.util.Properties getClientConnectionProperties()
  {
 Properties rc = super.getClientConnectionProperties();
  -  rc.setProperty(GenericConnectionFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.uil.UILClientILService);
  +  rc.setProperty(ServerILFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.uil.UILClientILService);
 return rc;
  }
   
  
  
  
  1.1  jbossmq/src/main/org/jboss/mq/il/uil/UILServerILFactory.java
  
  Index: UILServerILFactory.java
  ===
  /*
   * JBoss, the OpenSource J2EE webOS
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  package org.jboss.mq.il.uil;
  
  import java.util.Properties;
  
  import org.jboss.mq.il.ServerIL;
  import org.jboss.mq.il.ServerILFactory;
  import java.net.InetAddress;
  
  /**
   * Factory class to produce UILServerIL objects.
   *
   * @authora href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
   * @version   $Revision: 1.1 $
   */
  public class UILServerILFactory implements ServerILFactory {
  
 final public static String SERVER_IL_FACTORY = UILServerILFactory.class.getName();
 final public static String CLIENT_IL_SERVICE = 
UILClientILService.class.getName();  
 final public static String UIL_ADDRESS_KEY = UIL_ADDRESS_KEY;
 final public static String UIL_PORT_KEY = UIL_PORT_KEY;
  
 private ServerIL serverIL;
  
 /**
  * @see ServerILFactory#init(Properties)
  */
 public void init(Properties props) throws Exception {

String t = props.getProperty(UIL_ADDRESS_KEY);
if (t == null)
   throw new javax.jms.JMSException(A required connection property was not 
set:  + UIL_ADDRESS_KEY);
InetAddress address = InetAddress.getByName(t);
  
t = props.getProperty(UIL_PORT_KEY);
if (t == null)
   throw new javax.jms.JMSException(A required connection property was not 
set:  + UIL_PORT_KEY);
int port = Integer.parseInt(t);
  
serverIL = new UILServerIL(address, port);
  
 }
  
 /**
  * @see ServerILFactory#getServerIL()
  */
 public ServerIL getServerIL() throws Exception {
return serverIL;
 }
  
  }
  
  

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



[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/test ConnectionTestCase.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:14

  Added:   src/main/org/jboss/test/jbossmq/test ConnectionTestCase.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.1  
jbosstest/src/main/org/jboss/test/jbossmq/test/ConnectionTestCase.java
  
  Index: ConnectionTestCase.java
  ===
  /*
   * JBoss, the OpenSource J2EE webOS
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  package org.jboss.test.jbossmq.test;
  
  import junit.framework.Test;
  import junit.framework.TestCase;
  import javax.jms.*;
  import org.jboss.mq.SpyConnectionFactory;
  import org.jboss.test.JBossTestCase;
  import java.util.Properties;
  import org.jboss.mq.il.oil.OILServerILFactory;
  import org.jboss.mq.il.uil.UILServerILFactory;
  import org.jboss.mq.SpyXAConnectionFactory;
  import javax.naming.*;
  
  /** 
   * Test all the verious ways that a connection can be 
   * established with JBossMQ
   *
   * @author [EMAIL PROTECTED]
   * @version $Revision: 1.1 $
   */
  public class ConnectionTestCase extends JBossTestCase {
  
public ConnectionTestCase(String name) {
super(name);
}
  
protected void setUp() throws Exception {
}
  
public void testOILConnectViaJNDI() throws Exception {
InitialContext ctx = new InitialContext();

QueueConnectionFactory cf = 
(QueueConnectionFactory)ctx.lookup(ConnectionFactory);
QueueConnection c = cf.createQueueConnection();
c.close();

XAQueueConnectionFactory xacf = 
(XAQueueConnectionFactory)ctx.lookup(XAConnectionFactory);
XAQueueConnection xac = xacf.createXAQueueConnection();
xac.close();
}

public void testOILConnectNoJNDI() throws Exception {

Properties props = new Properties();
props.setProperty(OILServerILFactory.SERVER_IL_FACTORY_KEY, 
OILServerILFactory.SERVER_IL_FACTORY);
props.setProperty(OILServerILFactory.CLIENT_IL_SERVICE_KEY, 
OILServerILFactory.CLIENT_IL_SERVICE);
props.setProperty(OILServerILFactory.PING_PERIOD_KEY, 1000);
props.setProperty(OILServerILFactory.OIL_ADDRESS_KEY, localhost);
props.setProperty(OILServerILFactory.OIL_PORT_KEY,8090);

QueueConnectionFactory cf = new SpyConnectionFactory(props);
QueueConnection c = cf.createQueueConnection();
c.close();

XAQueueConnectionFactory xacf = new SpyXAConnectionFactory(props);
XAQueueConnection xac = xacf.createXAQueueConnection();
xac.close();

}

public void testUILConnectViaJNDI() throws Exception {
InitialContext ctx = new InitialContext();

QueueConnectionFactory cf = 
(QueueConnectionFactory)ctx.lookup(UILConnectionFactory);
QueueConnection c = cf.createQueueConnection();
c.close();

XAQueueConnectionFactory xacf = 
(XAQueueConnectionFactory)ctx.lookup(UILXAConnectionFactory);
XAQueueConnection xac = xacf.createXAQueueConnection();
xac.close();
}

public void testUILConnectNoJNDI() throws Exception {

Properties props = new Properties();
props.setProperty(UILServerILFactory.SERVER_IL_FACTORY_KEY, 
UILServerILFactory.SERVER_IL_FACTORY);
props.setProperty(UILServerILFactory.CLIENT_IL_SERVICE_KEY, 
UILServerILFactory.CLIENT_IL_SERVICE);
props.setProperty(UILServerILFactory.PING_PERIOD_KEY, 1000);
props.setProperty(UILServerILFactory.UIL_ADDRESS_KEY, localhost);
props.setProperty(UILServerILFactory.UIL_PORT_KEY,8091);

QueueConnectionFactory cf = new SpyConnectionFactory(props);
QueueConnection c = cf.createQueueConnection();
c.close();

XAQueueConnectionFactory xacf = new SpyXAConnectionFactory(props);
XAQueueConnection xac = xacf.createXAQueueConnection();
xac.close();
}
  
  
public static void main(java.lang.String[] args) {
junit.textui.TestRunner.run(ConnectionTestCase.class);
}
  }
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/jvm JVMServerILService.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:13

  Modified:src/main/org/jboss/mq/il/jvm JVMServerILService.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.5   +4 -3  jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerILService.java
  
  Index: JVMServerILService.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerILService.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JVMServerILService.java   2001/09/27 03:27:43 1.4
  +++ JVMServerILService.java   2001/10/21 05:38:13 1.5
  @@ -14,6 +14,7 @@
   import org.jboss.mq.il.ServerIL;
   import org.jboss.mq.il.ServerILJMXService;
   import org.jboss.mq.server.JMSServer;
  +import org.jboss.mq.il.ServerILFactory;
   
   import org.jboss.system.ServiceMBeanSupport;
   
  @@ -23,7 +24,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.4 $
  + * @version$Revision: 1.5 $
*/
   public class JVMServerILService extends org.jboss.mq.il.ServerILJMXService 
implements JVMServerILServiceMBean {
 
  @@ -56,8 +57,8 @@
   */
  public java.util.Properties getClientConnectionProperties() {
 Properties rc = super.getClientConnectionProperties();
  -  rc.setProperty( GenericConnectionFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.jvm.JVMClientILService );
  -  rc.setProperty( GenericConnectionFactory.SERVER_IL_FACTORY_KEY, 
org.jboss.mq.il.jvm.JVMServerILFactory );
  +  rc.setProperty( ServerILFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.jvm.JVMClientILService );
  +  rc.setProperty( ServerILFactory.SERVER_IL_FACTORY_KEY, 
org.jboss.mq.il.jvm.JVMServerILFactory );
 return rc;
  }
   
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/rmi RMIServerILService.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:13

  Modified:src/main/org/jboss/mq/il/rmi RMIServerILService.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.6   +3 -2  jbossmq/src/main/org/jboss/mq/il/rmi/RMIServerILService.java
  
  Index: RMIServerILService.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/rmi/RMIServerILService.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- RMIServerILService.java   2001/09/27 03:27:43 1.5
  +++ RMIServerILService.java   2001/10/21 05:38:13 1.6
  @@ -14,12 +14,13 @@
   import org.jboss.mq.il.ServerIL;
   import org.jboss.mq.il.ServerILJMXService;
   import org.jboss.mq.server.JMSServer;
  +import org.jboss.mq.il.ServerILFactory;
   
   /**
*  Implements the ServerILJMXService which is used to manage the JVM IL.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
  - * @version$Revision: 1.5 $
  + * @version$Revision: 1.6 $
*/
   public class RMIServerILService extends org.jboss.mq.il.ServerILJMXService 
implements RMIServerILServiceMBean
   {
  @@ -57,7 +58,7 @@
  public java.util.Properties getClientConnectionProperties()
  {
 Properties rc = super.getClientConnectionProperties();
  -  rc.setProperty(GenericConnectionFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.rmi.RMIClientILService);
  +  rc.setProperty(ServerILFactory.CLIENT_IL_SERVICE_KEY, 
org.jboss.mq.il.rmi.RMIClientILService);
 return rc;
  }
   
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il ServerILFactory.java ServerILJMXService.java

2001-10-20 Thread Hiram Chirino

  User: chirino 
  Date: 01/10/20 22:38:13

  Modified:src/main/org/jboss/mq/il ServerILFactory.java
ServerILJMXService.java
  Log:
  Feature add:
  You can now setup a JBossMQ connection with out using JNDI.
  The ConnectionTestCase has a test case in case your interested on how it
  is done.
  
  Revision  ChangesPath
  1.3   +15 -1 jbossmq/src/main/org/jboss/mq/il/ServerILFactory.java
  
  Index: ServerILFactory.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/ServerILFactory.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ServerILFactory.java  2001/08/17 03:04:03 1.2
  +++ ServerILFactory.java  2001/10/21 05:38:13 1.3
  @@ -15,9 +15,23 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public interface ServerILFactory {
  +
  +   /**
  +* Constant used to identify the property that holds the ServerILFactor class 
name
  +*/
  +   public final static String SERVER_IL_FACTORY_KEY = ServerILFactory;
  +   /**
  +* Constant used to identify the property that holds the ClientILService class 
name
  +*/
  +   public final static String CLIENT_IL_SERVICE_KEY = ClientILService;
  +   /**
  +* Constant used to identify the property that holds time period between server 
pings.
  +*/
  +   public final static String PING_PERIOD_KEY = PingPeriod;
  + 
  // init is called before any calls are made to getServerIL()
  public void init( Properties props )
 throws Exception;
  
  
  
  1.6   +2 -2  jbossmq/src/main/org/jboss/mq/il/ServerILJMXService.java
  
  Index: ServerILJMXService.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/ServerILJMXService.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ServerILJMXService.java   2001/09/27 03:27:43 1.5
  +++ ServerILJMXService.java   2001/10/21 05:38:13 1.6
  @@ -25,7 +25,7 @@
*  extended to provide a full implementation.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
  - * @version$Revision: 1.5 $
  + * @version$Revision: 1.6 $
*/
   public abstract class ServerILJMXService extends ServiceMBeanSupport implements 
ServerILJMXServiceMBean
   {
  @@ -59,7 +59,7 @@
  public java.util.Properties getClientConnectionProperties()
  {
 Properties rc = new Properties();
  -  rc.setProperty(GenericConnectionFactory.PING_PERIOD_KEY, +pingPeriod );
  +  rc.setProperty(ServerILFactory.PING_PERIOD_KEY, +pingPeriod );
 return rc;
  }
  
  
  
  

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



[JBoss-dev] Clustering is available for use

2001-10-20 Thread Bill Burke



Hi 
all,

Sacha Labourey and I 
would like to announce the availability of new JBoss clustering features in 
RabbitHole-3.0 (the mainline). There is still a lot of testing to be done 
so this is really BETA code. If you have any questions, pop either one of 
us an email on the jboss-dev list. I'll be in Las Vegas next week so 
hopefully Sacha can answer all questions for now. The below HOWTO will be 
merged into documentation eventually when one of us has 
time.

Regards,

Bill


Features

  You must have JDK 
  1.3.x Will not work with JDK earlier than this. 
  Sorry
  Built on top of 
  JavaGroups. http://www.javagroups.com
  Automatic group 
  discovery. Cluster nodes can automatically find eachother(BUT THEY DON"T 
  SHARE CONFIGURATIONS!)
  A general framework 
  wrapped around JavaGroups that provides group communications thru RPCs, a 
  state transfer protocol, and membership change notification
  Cluster-wide JNDI 
  (a.k.a HA-JNDI)
  Failover for 
  HA-JNDI, Stateless Session Beans, Entity Beans, and also any RMI object you 
  want to replicate
  method calls are 
  collocated if possible even if the proxy is serialized to another 
  node.
  SLSB, HA-JNDI, and 
  Home calls are load-balanced Round Robin. Entity Bean calls are NOT 
  load-balanced.
Quick 
Start

  Get latest and 
  build from CVS mainline (RH 3.0) (Don't ask me how to do 
  this!)
  Copy 
  .../jboss-all/cluster/etc/cluster-service.xml to JBoss's deploy/ 
  directory
  Edit any SLSB or 
  EntityBean's "jboss.xml" to put in clustered flag (see 
  .../jboss-all/cluster/etc/jboss.xml for example

  i.e.
  
  jboss 
  securefalse/secure
   
  enterprise-beans 
  session 
  ejb-namenextgen.StatelessSession/ejb-name 
  jndi-namenextgen.StatelessSession/jndi-nameclusteredTrue/clustered 
  /session 
  entity 
  ejb-namenextgen.EnterpriseEntity/ejb-name 
  jndi-namenextgen.EnterpriseEntity/jndi-name 
  clusteredTrue/clustered 
  /entity/enterprise-beans
  
  /jboss

  
  To use HA-JNDI you must have 
  a list of cluster nodes in the provider URL list separated by commas, HA-JNDI 
  runs off of port 1100 by default:

  java.naming.provider.url=server1:1100,server2:1100,server3:1100
  

  
  HA-JNDI is NOT a required service. You can 
  connect to any cluster node's local JNDI.
Problems you 
may encounter

  Only JDK 1.3.x is 
  supported. It will not work with an earlier JDK.
  Do NOT use 
  commit-option 'A' with Entity Beans!!!
  If you want to 
  synchronize Entity Beans across the cluster use select-for-update 
  Unfortunately this feature may only work with Oracle :-(. We will be 
  expanding this feature later on.
  Clustered beans do 
  NOT support Transaction Propagation unless the method call is 
  collocated.
  We think we've 
  fixed this problem, but if you bring 2 clustered nodes up at the same time and 
  have problems, start them completely one at a time.
  MERGEing doesn't 
  work well yet. What is Merging? Let's say a part of the cluster 
  becomes separated from the group because of a bad network switch or 
  something. These orphaned nodes don't die, but are just cut off from the 
  network. When these orphaned nodes are hooked up to the network again, 
  JBoss Clustering(through JavaGroups) will merge the orphaned nodes into the 
  group. This does not work well all the time.


Advanced 
Setup

How clustering is configured will expand over time, but 
here's what can be configured right now.

Advanced 
Cluster Configuration
One JBoss instance 
can belong to multiple different clusters.(Beans can only belong to one cluster 
though!) You can do this by plopping another mbean into jboss and give a 
name for the specific cluster. 

Cluster 
configuration variables(these can be defined as mbean properties in 
cluster-service.xml for example):
PartitionName: Name the cluster 
partition. The default is "DefaultPartition"
PartitionProperties: Defines JavaGroups 
properties. see http://www.javagroups.com for more 
information

i.e.

server
 classpath 
archives="jbossha.jar"/
 
dependsJBOSS-SYSTEM:service=Naming/depends
 !-- 
 
-- !-- Cluster Partition: defines 
cluster 
-- !-- 
 
--
 mbean 
code="org.jboss.ha.framework.server.ClusterPartition" 
name="JBOSS-SYSTEM:service=DefaultPartition"
 
attribute 
name="PartitionName"MySpecialPartition/attribute
 
attribute 
name="PartitionProperties"UDP:PING:FD:VERIFY_SUSPECT:MERGE:NAKACK(trace=true):UNICAST:FRAG:FLUSH:GMS:STATE_TRANSFER:QUEUE/attribute
 
/mbean
/server
Advanced 
HA-JNDI Confugration
You can only define the JNDI listen port at this time in 
the mbean. The default is 1100

i.e.

server

 classpath 
archives="jbossha.jar"/

 
dependsJBOSS-SYSTEM:service=Naming/depends

 !-- 
 
-- !-- Cluster Partition: defines 
cluster 
-- !-- 

RE: [JBoss-dev] Clustering is available for use

2001-10-20 Thread marc fleury



Oh 
fuck this is sooo pretty...

I 
can't wait to see you guys in Vegas.

I'll 
say, we rule!

marcf

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Bill 
  BurkeSent: Saturday, October 20, 2001 6:20 PMTo: 
  Jboss-User@Lists. Sourceforge. Net; Jboss-Development@Lists. Sourceforge. 
  NetSubject: [JBoss-dev] Clustering is available for 
  use
  Hi 
  all,
  
  Sacha Labourey and 
  I would like to announce the availability of new JBoss clustering features in 
  RabbitHole-3.0 (the mainline). There is still a lot of testing to be 
  done so this is really BETA code. If you have any questions, pop either 
  one of us an email on the jboss-dev list. I'll be in Las Vegas next week 
  so hopefully Sacha can answer all questions for now. The below HOWTO 
  will be merged into documentation eventually when one of us has 
  time.
  
  Regards,
  
  Bill
  
  
  Features
  
You must have JDK 
1.3.x Will not work with JDK earlier than this. 
Sorry 
Built on top of 
JavaGroups. http://www.javagroups.com 

Automatic group 
discovery. Cluster nodes can automatically find eachother(BUT THEY 
DON"T SHARE CONFIGURATIONS!) 
A general 
framework wrapped around JavaGroups that provides group communications thru 
RPCs, a state transfer protocol, and membership change 
notification 
Cluster-wide JNDI 
(a.k.a HA-JNDI) 
Failover for 
HA-JNDI, Stateless Session Beans, Entity Beans, and also any RMI object you 
want to replicate 
method calls are 
collocated if possible even if the proxy is serialized to another 
node. 
SLSB, HA-JNDI, 
and Home calls are load-balanced Round Robin. Entity Bean calls are 
NOT load-balanced.
  Quick 
  Start
  
Get latest and 
build from CVS mainline (RH 3.0) (Don't ask me how to do 
this!) 
Copy 
.../jboss-all/cluster/etc/cluster-service.xml to JBoss's deploy/ 
directory 
Edit any SLSB or 
EntityBean's "jboss.xml" to put in clustered flag (see 
.../jboss-all/cluster/etc/jboss.xml for example
  
i.e.

jboss 
securefalse/secure
 
enterprise-beans 
session 
ejb-namenextgen.StatelessSession/ejb-name 
jndi-namenextgen.StatelessSession/jndi-nameclusteredTrue/clustered 
/session 
entity 
ejb-namenextgen.EnterpriseEntity/ejb-name 
jndi-namenextgen.EnterpriseEntity/jndi-name 
clusteredTrue/clustered 
/entity/enterprise-beans

/jboss
  

To use HA-JNDI you must 
have a list of cluster nodes in the provider URL list separated by commas, 
HA-JNDI runs off of port 1100 by default:
  
java.naming.provider.url=server1:1100,server2:1100,server3:1100

  

HA-JNDI is NOT a required service. You can 
connect to any cluster node's local JNDI.
  Problems 
  you may encounter
  
Only JDK 1.3.x is 
supported. It will not work with an earlier JDK. 
Do NOT use 
commit-option 'A' with Entity Beans!!! 
If you want to 
synchronize Entity Beans across the cluster use select-for-update 
Unfortunately this feature may only work with Oracle :-(. We will be 
expanding this feature later on. 
Clustered beans 
do NOT support Transaction Propagation unless the method call is 
collocated. 
We think we've 
fixed this problem, but if you bring 2 clustered nodes up at the same time 
and have problems, start them completely one at a time. 
MERGEing doesn't 
work well yet. What is Merging? Let's say a part of the cluster 
becomes separated from the group because of a bad network switch or 
something. These orphaned nodes don't die, but are just cut off from 
the network. When these orphaned nodes are hooked up to the network 
again, JBoss Clustering(through JavaGroups) will merge the orphaned nodes 
into the group. This does not work well all the 
time.
  
  
  Advanced 
  Setup
  
  How clustering is configured will expand over time, 
  but here's what can be configured right now.
  
  Advanced 
  Cluster Configuration
  One JBoss instance 
  can belong to multiple different clusters.(Beans can only belong to one 
  cluster though!) You can do this by plopping another mbean into jboss 
  and give a name for the specific cluster. 
  
  Cluster 
  configuration variables(these can be defined as mbean properties in 
  cluster-service.xml for example):
  PartitionName: Name the cluster 
  partition. The default is "DefaultPartition"
  PartitionProperties: Defines JavaGroups 
  properties. see http://www.javagroups.com for more 
  information
  
  i.e.
  
  server
   
  classpath archives="jbossha.jar"/
   
  dependsJBOSS-SYSTEM:service=Naming/depends
   !-- 
   
  -- !-- Cluster Partition: defines 
  cluster 
  -- !-- 
   
  --
   mbean