[JBoss-dev] bug in jbossmq.xml

2001-08-21 Thread Schouten, Andreas

Hello,

some day ago I added a bug report at sourceforge. The first line in file 

jBoss/conf/default and jboss/conf/tomcat
reads
?xml version=1.0 encoding=UTF8?
instead of
?xml version=1.0 encoding=UTF-8?
because of this jBossmq doesn't start with xerces.

The binary distribution version 2.4.0.23 still contains this bug!

It's a small typo but newbies may get a bad first impression of jBoss, if it
does not run out of the box.
Is there a mechanism that someone desides if a update of the binary
distibution is nessesary after code changes?

Andreas

Scott, somebody must have fixed it bevore You checked that the source is ok.




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



[JBoss-dev] [ jboss-Feature Requests-453650 ] validation improvements

2001-08-21 Thread noreply

Feature Requests item #453650, was opened at 2001-08-21 00:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376688aid=453650group_id=22866

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: validation improvements

Initial Comment:
If a method is declared direct in a home, remote or 
local interface, but not implemented in the bean class 
the validator reports a message while deploying the 
app.

But if the method is declared in an super interface 
the validator check fails.

In this case the method setupHomeMappingImpl in class 
EntityContainer (or a aquivalent) throws a deploeyment 
exception.
But this exception only report the method not the bean 
or interface name.
so one has to check all beans which interfaces 
implements this super interface.

Wy doesen't the validator check also methods inherit 
form super interfaces?

--

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

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



Re: [JBoss-dev] SQL function mapping

2001-08-21 Thread Marco Ladermann

On Monday, 20. August 2001 19:20, Dain Sundstrom wrote:
 Thanks, checked it in.

 -dain


snip

  It is simply two functions
 
  position(?2 in substring(?1 from ?3))+?3
 

Sorry for complaining so late, but it is not as simple as this.

position( 'findme' , 'wheretolookfor', 3) should be 0 and not 3  or am I 
wrong?

Therefore use this for PostgreSQL:

coalesce( nullif( position( ?1 in substring( ?1 from ?3 ) ), ?3 ) + ?3, 0 )

Marco

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



Re: [JBoss-dev] SQL function mapping

2001-08-21 Thread Dave Smith

Nope your right. When I first wrote the function I did not have the + ?3 
at the end so it worked fine ...

Marco Ladermann wrote:
 On Monday, 20. August 2001 19:20, Dain Sundstrom wrote:
 
Thanks, checked it in.

-dain


 
 snip
 
It is simply two functions

position(?2 in substring(?1 from ?3))+?3


 
 Sorry for complaining so late, but it is not as simple as this.
 
 position( 'findme' , 'wheretolookfor', 3) should be 0 and not 3  or am I 
 wrong?
 
 Therefore use this for PostgreSQL:
 
 coalesce( nullif( position( ?1 in substring( ?1 from ?3 ) ), ?3 ) + ?3, 0 )
 
 Marco
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 



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



[JBoss-dev] Extra ;

2001-08-21 Thread Dave Smith

Dain in server/src/main/org/jboss/ejb/plugins/cmp/ejbql/Parser.java line 
66 you have an extra ';' terminating the return statement. It is causing 
jikes to complain.

Found 1 semantic error compiling 
/home/dave/jboss/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/Parser.java:
 [javac]
 [javac] 66. return 
(Assembly)completeMatches.iterator().next();;
 [javac] 
 ^
 [javac] *** Error: This statement is unreachable.

Could you take it out? Thanks ..


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



Re: [JBoss-dev] 2.4.0 has been released

2001-08-21 Thread Julian Gosnell

The bundle that I pulled down from SF :

http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.zip

contains 2 entire JBoss distribs and hence is twice
the size of a normal download...

I diffed them.

lib/ext/jboss.jar differed between them.
the one with the BETA suffix had a load of extra dirs

Is this intentional - I was confisued as to which one
I should use to build JBoss/Jetty.

Jules


 --- Scott M Stark [EMAIL PROTECTED] wrote: 
The initial release of the 2.4.0 binary has been
 released and is available at
 sourceforge.
 
  


Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

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



Re: [JBoss-dev] bug in jbossmq.xml

2001-08-21 Thread Scott M Stark

This does not exist in the 2.4.0 final release made yesterday.

- Original Message -
From: Schouten, Andreas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 12:06 AM
Subject: [JBoss-dev] bug in jbossmq.xml


 Hello,

 some day ago I added a bug report at sourceforge. The first line in file

 jBoss/conf/default and jboss/conf/tomcat
 reads
 ?xml version=1.0 encoding=UTF8?
 instead of
 ?xml version=1.0 encoding=UTF-8?
 because of this jBossmq doesn't start with xerces.

 The binary distribution version 2.4.0.23 still contains this bug!

 It's a small typo but newbies may get a bad first impression of jBoss, if
it
 does not run out of the box.
 Is there a mechanism that someone desides if a update of the binary
 distibution is nessesary after code changes?

 Andreas

 Scott, somebody must have fixed it bevore You checked that the source is
ok.




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



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



Re: [JBoss-dev] 2.4.0 has been released

2001-08-21 Thread Scott M Stark

Not intended. I gues the dist target doesn't clean out any existing dirs
before creating the archive. I'll repackage it.

- Original Message - 
From: Julian Gosnell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 4:56 AM
Subject: Re: [JBoss-dev] 2.4.0 has been released


 The bundle that I pulled down from SF :
 
 http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.zip
 
 contains 2 entire JBoss distribs and hence is twice
 the size of a normal download...
 
 I diffed them.
 
 lib/ext/jboss.jar differed between them.
 the one with the BETA suffix had a load of extra dirs
 
 Is this intentional - I was confisued as to which one
 I should use to build JBoss/Jetty.
 
 Jules
 
 
  --- Scott M Stark [EMAIL PROTECTED] wrote: 
 The initial release of the 2.4.0 binary has been
  released and is available at
  sourceforge.
  
   
 
 
 Do You Yahoo!?
 Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
 or your free @yahoo.ie address at http://mail.yahoo.ie
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 


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



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

2001-08-21 Thread Scott M Stark

  User: starksm 
  Date: 01/08/21 08:37:52

  Modified:src/etc/conf/default Tag: Branch_2_4 mail.properties
  Log:
  Don't use Simone's mail info as the default
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.4.1   +12 -6 jboss/src/etc/conf/default/mail.properties
  
  Index: mail.properties
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/mail.properties,v
  retrieving revision 1.2
  retrieving revision 1.2.4.1
  diff -u -r1.2 -r1.2.4.1
  --- mail.properties   2001/04/20 22:55:30 1.2
  +++ mail.properties   2001/08/21 15:37:51 1.2.4.1
  @@ -1,7 +1,13 @@
  -mail.store.protocol  = pop3
  +# Change to your mail server prototocol
  +mail.store.protocol = pop3
   mail.transport.protocol = smtp
  -mail.user= biorn_steedom
  -mail.pop3.host   = pop.mail.yahoo.com
  -mail.smtp.host   = smtp.mail.yahoo.com
  -mail.from= [EMAIL PROTECTED]
  -mail.debug   = false
  +# Change to the user who will receive mail
  +mail.user = to_user
  +# Change to the mail server 
  +mail.pop3.host = pop.dot.com
  +# Change to the SMTP gateway server
  +mail.smtp.host = smtp.dot.com
  +# Change to the address mail will be from
  +mail.from = [EMAIL PROTECTED]
  +# Enable debugging output from the javamail classes
  +mail.debug = false
  
  
  

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



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

2001-08-21 Thread Scott M Stark

  User: starksm 
  Date: 01/08/21 08:57:19

  Modified:src/etc/conf/default mail.properties
  Log:
  Change the default properties from Simone's to values that
  must be customized
  
  Revision  ChangesPath
  1.4   +13 -7 jboss/src/etc/conf/default/mail.properties
  
  Index: mail.properties
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/mail.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- mail.properties   2001/08/11 21:32:45 1.3
  +++ mail.properties   2001/08/21 15:57:18 1.4
  @@ -4,12 +4,18 @@
   ##  ##
   ### == ###
   
  -### $Id: mail.properties,v 1.3 2001/08/11 21:32:45 user57 Exp $ ###
  +### $Id: mail.properties,v 1.4 2001/08/21 15:57:18 starksm Exp $ ###
   
  -mail.store.protocol = pop3
  +# Change to your mail server prototocol
  +mail.store.protocol = pop3
   mail.transport.protocol = smtp
  -mail.user   = biorn_steedom
  -mail.pop3.host  = pop.mail.yahoo.com
  -mail.smtp.host  = smtp.mail.yahoo.com
  -mail.from   = [EMAIL PROTECTED]
  -mail.debug  = false
  +# Change to the user who will receive mail
  +mail.user = to_user
  +# Change to the mail server 
  +mail.pop3.host = pop.dot.com
  +# Change to the SMTP gateway server
  +mail.smtp.host = smtp.dot.com
  +# Change to the address mail will be from
  +mail.from = [EMAIL PROTECTED]
  +# Enable debugging output from the javamail classes
  +mail.debug = false
  
  
  

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



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

2001-08-21 Thread Scott M Stark

  User: starksm 
  Date: 01/08/21 09:13:33

  Modified:.binary.jsp
  Log:
  Update the size and dates of the 2.4.0 release
  
  Revision  ChangesPath
  1.9   +4 -4  newsite/binary.jsp
  
  Index: binary.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/binary.jsp,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- binary.jsp2001/08/21 01:06:41 1.8
  +++ binary.jsp2001/08/21 16:13:33 1.9
  @@ -36,14 +36,14 @@
 
 tr
   tda class=link 
href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.zip;JBoss-2.4.0.zip/a/td
  -td align=centerp class=text16233873/td
  -td align=centerp class=textAugust 20, 2001/td
  +td align=centerp class=text8109497/td
  +td align=centerp class=textAugust 21, 2001/td
 /tr
   
 tr
   tda class=link 
href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0_Tomcat-3.2.3.zip;JBoss-2.4.0_Tomcat-3.2.3.zip/a/td
  -td align=centerp class=text11414416/td
  -td align=centerp class=textAugust 20, 2001/td
  +td align=centerp class=text11415568/td
  +td align=centerp class=textAugust 21, 2001/td
 /tr
   
 tr
  
  
  

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



Re: [JBoss-dev] 2.4.0 has been released

2001-08-21 Thread Scott M Stark

The new package has been placed on sourceforge. This should appear soon
under the
Files section, but is available now via
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.zip

- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 8:22 AM
Subject: Re: [JBoss-dev] 2.4.0 has been released


 Not intended. I gues the dist target doesn't clean out any existing dirs
 before creating the archive. I'll repackage it.

 - Original Message -
 From: Julian Gosnell [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, August 21, 2001 4:56 AM
 Subject: Re: [JBoss-dev] 2.4.0 has been released


  The bundle that I pulled down from SF :
 
  http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.zip
 
  contains 2 entire JBoss distribs and hence is twice
  the size of a normal download...
 
  I diffed them.
 
  lib/ext/jboss.jar differed between them.
  the one with the BETA suffix had a load of extra dirs
 
  Is this intentional - I was confisued as to which one
  I should use to build JBoss/Jetty.
 
  Jules
 
 
   --- Scott M Stark [EMAIL PROTECTED] wrote: 
  The initial release of the 2.4.0 binary has been
   released and is available at
   sourceforge.
  
  
 
  
  Do You Yahoo!?
  Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
  or your free @yahoo.ie address at http://mail.yahoo.ie
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
 


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



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



RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()

2001-08-21 Thread Bill Burke

Jason,

I'm going to combine multiple email replies into one.  Please switch back to
QueuedPessimisticEJBLock.  We're trying to make this the default for JBoss
since it scales better.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Monday, August 20, 2001 7:06 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()


 I am using commit option B, since it might be possible that
 another process
 is using the database... though I am 100% sure that I have sole access to
 the database I am using.


You probably already know this but ejbLoad will get called whenever the
entity becomes part of the transaction

 If I run the first producer with the first MDB offline, then
 connect the MDB
 everything seems to be fine.  I have run a few tests through in
 this manner
 and I have not had problem yet, where as if I try to have the both up
 together it will work only once after all nodes have been started
 (usually)
 and will fail most times after that.

 I should be able to have more than one thread update a single
 entity at the
 same time (or rather ordered as the container dictates) right?


By more than one thread you mean more than one transaction?  Yes, you can
have more than one transaction, but remember, this is pessimistic locking.
The entity will be locked until the transaction commits.  All other accesses
to the entity will be blocked until the entity is committed by the first
transaction.


 
  so you see:
  1. setModified()
  2. ejbLoad
 
  So there is no ejbStore() in between setModified() and ejbLoad()?

 Correct.  I also very rarly a javax.ejb.DuplicateKeyException,
 which happend
 to just pop up as I was running these tests.

  I assume you're using commit option 'A'?

 Nope, option 'B'.


isModified only get's called before a storeEntity(ejbStore())  It does not
get called before an ejbLoad().  storeEntity will get called on a
transaction commit. Also when a finder or remove method is called, but only
beans within the transaction will get stored in this case.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Monday, August 20, 2001 7:34 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()


 On Mon, 20 Aug 2001, Bill Burke wrote:
 
  A thing to note.  Whenever a finder or remove is called within a
  transaction, every entity of every type that is part of the
 transaction is
  synchronized with the database.  Could this be your problem?

 The (5) MDB uses findByPrimaryKey to locate all of the beans (a,
 b, c  d).

 So, if there is an entity and modified by one thread under one tx, and
 another thread/tx does a findby, the first thread will loose its
 data due to
 a ejbLoad from the second?


Not at all.  Remember.  Pessimistic locking!  Once an entity becomes part of
a tx, all other threads/transactions are blocked until the tx commits.

 This is essentially what I am seeing, though I can not really
 tell that this

I just found a bug in QueuedPessimisticEJBLock that may be causing this
problem.



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



[JBoss-dev] Clustering and SOAP

2001-08-21 Thread Richard Emberson

Is there an archive where the results of the jboss discussion on
how clustering will be implemented (and when) in JBoss?

I assume that the clustering is for horizontal load balancing, fail over,
etc.
and that vertical mechanism are already done.

Is there a summary of the discussion as to why a separate SOAP
implementation was done (zoap) rather than use the apache SOAP?

Thanks.

RME


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



AW: [JBoss-dev] Clustering and SOAP

2001-08-21 Thread Jung , Dr. Christoph

-Ursprüngliche Nachricht-
Von: Richard Emberson [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 21. August 2001 18:35
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Clustering and SOAP

Is there a summary of the discussion as to why a separate SOAP
implementation was done (zoap) rather than use the apache SOAP?

Cos apache-SOAP (still) sucks, IMHO. 

Wait. Polemics off. At the time we started with ZOAP (must have been late 
2000, or so, cant remember the exact month), ApacheSOAP was 
hardly able to serialize serious data structures besides the strings and
numerics 
from the StockTicker demo  (not to mention  the performance issues due to
using DOM). 

Due to a lacking acceptance of ZOAP, however, we have decided to abandon the
ZOAP 
effort in favor to Apache/Axis/whatever.

Unfortunately, there is not yet enough critical mass to form a new
subproject, the exact
target (Invocation layer, JMX adaptor, JMS integration) is also not clear.
But
at least discussion is underway ...

CGJ

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



Re: [JBoss-dev] Clustering and SOAP

2001-08-21 Thread David Jencks

I'm not sure about the clustering stuff, but ZOAP was developed before
Apache SOAP was very usable.  Since apache SOAP has become more functional
ZOAP is no longer under development.  Search for posts by Dr. Jung.

On 2001.08.21 12:34:58 -0400 Richard Emberson wrote:
 Is there an archive where the results of the jboss discussion on
 how clustering will be implemented (and when) in JBoss?
 
 I assume that the clustering is for horizontal load balancing, fail over,
 etc.
 and that vertical mechanism are already done.
 
 Is there a summary of the discussion as to why a separate SOAP
 implementation was done (zoap) rather than use the apache SOAP?
 
 Thanks.
 
 RME
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



Re: [JBoss-dev] bug in jbossmq.xml

2001-08-21 Thread Hiram Chirino

To fully fix that bug, I recently changed the:
jbossmq\src\main\org\jbossmq\xml\XElement.java
file.  JBossMQ was incorrectly rewriting the jbossmq.xml with the UTF8 
string.  I commited the change to the 2.4 branch..  But I don't know if it 
was rebuilt and included in the jboss libs for the final release.

Regards,
Hiram

From: Scott M Stark [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] bug in jbossmq.xml
Date: Tue, 21 Aug 2001 07:32:53 -0700

This does not exist in the 2.4.0 final release made yesterday.

- Original Message -
From: Schouten, Andreas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 12:06 AM
Subject: [JBoss-dev] bug in jbossmq.xml


  Hello,
 
  some day ago I added a bug report at sourceforge. The first line in file
 
  jBoss/conf/default and jboss/conf/tomcat
  reads
  ?xml version=1.0 encoding=UTF8?
  instead of
  ?xml version=1.0 encoding=UTF-8?
  because of this jBossmq doesn't start with xerces.
 
  The binary distribution version 2.4.0.23 still contains this bug!
 
  It's a small typo but newbies may get a bad first impression of jBoss, 
if
it
  does not run out of the box.
  Is there a mechanism that someone desides if a update of the binary
  distibution is nessesary after code changes?
 
  Andreas
 
  Scott, somebody must have fixed it bevore You checked that the source is
ok.
 
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
 


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


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


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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2001-08-21 Thread Bill Burke

  User: patriot1burke
  Date: 01/08/21 11:35:51

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  Needed to set tx after obtaining lock
  
  Revision  ChangesPath
  1.3   +12 -9 
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- QueuedPessimisticEJBLock.java 2001/08/08 22:13:00 1.2
  +++ QueuedPessimisticEJBLock.java 2001/08/21 18:35:51 1.3
  @@ -42,7 +42,7 @@
* @author a href=[EMAIL PROTECTED]Marc Fleury/a
* @author a href=[EMAIL PROTECTED]Bill Burke/a
*
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
*
* pbRevisions:/bbr
* pb2001/08/03: billb/b
  @@ -156,10 +156,10 @@
  protected boolean doSchedule(MethodInvocation mi) 
 throws Exception
  {
  -  this.sync();
 boolean wasThreadScheduled = false;
 Transaction miTx = mi.getTransaction();
 boolean trace = log.isTraceEnabled();
  +  this.sync();
 try
 {
if( trace ) log.trace(Begin schedule, key=+mi.getId());
  @@ -249,9 +249,9 @@
 // We loop here until either until success or until transaction timeout
 // If we get out of the loop successfully, we can successfully
 // set the transaction on this puppy.
  -  while (tx != null 
  +  while (this.tx != null 
// And are we trying to enter with another transaction?
  - !tx.equals(miTx))
  + !this.tx.equals(miTx))
 {
wasScheduled = true;
// That's no good, only one transaction per context
  @@ -260,7 +260,7 @@

TxLock txLock = getTxLock(miTx);

  - if( trace ) log.trace(Begin wait on Tx=+tx);
  + if( trace ) log.trace(Begin wait on Tx=+this.tx);

// And lock the threads on the lock corresponding to the Tx in MI
synchronized(txLock)
  @@ -274,7 +274,7 @@

this.sync();

  - if( trace ) log.trace(End wait on TxLock=+tx);
  + if( trace ) log.trace(End wait on TxLock=+this.tx);
if (isTxExpired(miTx))
{
   log.error(Thread.currentThread() + Saw rolled back tx=+miTx+ waiting 
for txLock
  @@ -289,7 +289,7 @@
  txLocks.remove(txLock);
  txWaitQueue.remove(txLock);
   }
  -else if (tx != null  tx.equals(miTx))
  +else if (this.tx != null  tx.equals(miTx))
   {
  // We're not qu
  nextTransaction();
  @@ -297,6 +297,9 @@
   throw new RuntimeException(Transaction marked for rollback, possibly a 
timeout);
}
 } // end while(tx!=miTx)
  +
  +  // If we get here, this means that we have the txlock
  +  this.tx = miTx;
 return wasScheduled;
  }
   
  @@ -405,7 +408,7 @@
 if (numMethodLocks == 0)
 {
synchronized(methodLock) {methodLock.notify();}
  -  }
  +  } 
  }
  
  /*
  @@ -438,7 +441,7 @@
// saveStackTrace(removing bean lock and it has tx's in 
QUEUE!***);
throw new IllegalStateException(removing bean lock and it has tx's in 
QUEUE!);
 }
  -  else if (refs == 0  tx != null) 
  +  else if (refs == 0  this.tx != null) 
 {
// saveStackTrace(removing bean lock and it has tx set!***);
throw new IllegalStateException(removing bean lock and it has tx set!);
  
  
  

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



RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()

2001-08-21 Thread Jason Dillon

 I'm going to combine multiple email replies into one.  Please switch back to
 QueuedPessimisticEJBLock.  We're trying to make this the default for JBoss
 since it scales better.

Ok.  I was not sure if one was more stable than the other.

  I am using commit option B, since it might be possible that
  another process
  is using the database... though I am 100% sure that I have sole access to
  the database I am using.

 You probably already know this but ejbLoad will get called whenever the
 entity becomes part of the transaction

I figured that much, but I was not really sure.

  If I run the first producer with the first MDB offline, then
  connect the MDB
  everything seems to be fine.  I have run a few tests through in
  this manner
  and I have not had problem yet, where as if I try to have the both up
  together it will work only once after all nodes have been started
  (usually)
  and will fail most times after that.
 
  I should be able to have more than one thread update a single
  entity at the
  same time (or rather ordered as the container dictates) right?

 By more than one thread you mean more than one transaction?  Yes, you can
 have more than one transaction, but remember, this is pessimistic locking.
 The entity will be locked until the transaction commits.  All other accesses
 to the entity will be blocked until the entity is committed by the first
 transaction.

That is not the behavior that I was seeing, perhaps your change to Queued*
fixed that.  Not sure at the moment.  I think I did find one rather large
application error, where the last MDB updated an entity, and then tried to
remove it (and all other related entities) at the end, all inside of one tx.
I made a dumb ass mistake and changed the method which removed these to be
NotSupported, which was causing a TX timeout waiting for the calling TX to
complete before anything could be removed...  Since the last update never
commits, the database always looks inconsistent.  Any ways, I think that this
was the problem that I was seeing with the Simple* lock.

 Not at all.  Remember.  Pessimistic locking!  Once an entity becomes part of
 a tx, all other threads/transactions are blocked until the tx commits.

  This is essentially what I am seeing, though I can not really
  tell that this

 I just found a bug in QueuedPessimisticEJBLock that may be causing this
 problem.

Cool.  I will let you know if this fixes the problem I am seeing.

--jason


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



RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()

2001-08-21 Thread Bill Burke



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Tuesday, August 21, 2001 4:36 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()


  I'm going to combine multiple email replies into one.  Please
 switch back to
  QueuedPessimisticEJBLock.  We're trying to make this the
 default for JBoss
  since it scales better.

 Ok.  I was not sure if one was more stable than the other.

   I am using commit option B, since it might be possible that
   another process
   is using the database... though I am 100% sure that I have
 sole access to
   the database I am using.
 
  You probably already know this but ejbLoad will get called whenever the
  entity becomes part of the transaction

 I figured that much, but I was not really sure.

   If I run the first producer with the first MDB offline, then
   connect the MDB
   everything seems to be fine.  I have run a few tests through in
   this manner
   and I have not had problem yet, where as if I try to have the both up
   together it will work only once after all nodes have been started
   (usually)
   and will fail most times after that.
  
   I should be able to have more than one thread update a single
   entity at the
   same time (or rather ordered as the container dictates) right?
 
  By more than one thread you mean more than one transaction?
 Yes, you can
  have more than one transaction, but remember, this is
 pessimistic locking.
  The entity will be locked until the transaction commits.  All
 other accesses
  to the entity will be blocked until the entity is committed by the first
  transaction.

 That is not the behavior that I was seeing, perhaps your change to Queued*
 fixed that.  Not sure at the moment.  I think I did find one rather large

The Queued* bug fix should show the behaviour I talked about above.  Let me
know.

Thanks,

Bill



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



RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()

2001-08-21 Thread Jason Dillon

I have not seen this problem again... so far.  I am running larger tests to
confirm.

--jason


On Tue, 21 Aug 2001, Bill Burke wrote:



  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
  Dillon
  Sent: Tuesday, August 21, 2001 4:36 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
 
 
   I'm going to combine multiple email replies into one.  Please
  switch back to
   QueuedPessimisticEJBLock.  We're trying to make this the
  default for JBoss
   since it scales better.
 
  Ok.  I was not sure if one was more stable than the other.
 
I am using commit option B, since it might be possible that
another process
is using the database... though I am 100% sure that I have
  sole access to
the database I am using.
  
   You probably already know this but ejbLoad will get called whenever the
   entity becomes part of the transaction
 
  I figured that much, but I was not really sure.
 
If I run the first producer with the first MDB offline, then
connect the MDB
everything seems to be fine.  I have run a few tests through in
this manner
and I have not had problem yet, where as if I try to have the both up
together it will work only once after all nodes have been started
(usually)
and will fail most times after that.
   
I should be able to have more than one thread update a single
entity at the
same time (or rather ordered as the container dictates) right?
  
   By more than one thread you mean more than one transaction?
  Yes, you can
   have more than one transaction, but remember, this is
  pessimistic locking.
   The entity will be locked until the transaction commits.  All
  other accesses
   to the entity will be blocked until the entity is committed by the first
   transaction.
 
  That is not the behavior that I was seeing, perhaps your change to Queued*
  fixed that.  Not sure at the moment.  I think I did find one rather large

 The Queued* bug fix should show the behaviour I talked about above.  Let me
 know.

 Thanks,

 Bill



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



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



RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()

2001-08-21 Thread Jason Dillon

I have pushed close to 600x3 transactions through our system and have not
run into any problems yet.  Once I get to 1000x3 I will know for sure.

Looks really good so far!

--jason


On Tue, 21 Aug 2001, Jason Dillon wrote:

 I have not seen this problem again... so far.  I am running larger tests to
 confirm.

 --jason


 On Tue, 21 Aug 2001, Bill Burke wrote:

 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
   Dillon
   Sent: Tuesday, August 21, 2001 4:36 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
  
  
I'm going to combine multiple email replies into one.  Please
   switch back to
QueuedPessimisticEJBLock.  We're trying to make this the
   default for JBoss
since it scales better.
  
   Ok.  I was not sure if one was more stable than the other.
  
 I am using commit option B, since it might be possible that
 another process
 is using the database... though I am 100% sure that I have
   sole access to
 the database I am using.
   
You probably already know this but ejbLoad will get called whenever the
entity becomes part of the transaction
  
   I figured that much, but I was not really sure.
  
 If I run the first producer with the first MDB offline, then
 connect the MDB
 everything seems to be fine.  I have run a few tests through in
 this manner
 and I have not had problem yet, where as if I try to have the both up
 together it will work only once after all nodes have been started
 (usually)
 and will fail most times after that.

 I should be able to have more than one thread update a single
 entity at the
 same time (or rather ordered as the container dictates) right?
   
By more than one thread you mean more than one transaction?
   Yes, you can
have more than one transaction, but remember, this is
   pessimistic locking.
The entity will be locked until the transaction commits.  All
   other accesses
to the entity will be blocked until the entity is committed by the first
transaction.
  
   That is not the behavior that I was seeing, perhaps your change to Queued*
   fixed that.  Not sure at the moment.  I think I did find one rather large
 
  The Queued* bug fix should show the behaviour I talked about above.  Let me
  know.
 
  Thanks,
 
  Bill
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
 


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



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



[JBoss-dev] manual build

2001-08-21 Thread Vincent Harcq

Hi,
Is there anybody trying to make the manual build run correctly?

I give it a (painful) try.
I succeed to build a part of html and printable-html (hum simply the
preface,intro, cmp and jaws for the moment)

I choose to move to ant 1.4 that use JAXP 1.1 to avoid problems with style,
xsl, ...
I needed to change the jboss-all/build/build.bat to include sun/jaxp and
ant/lib/ext jars.
The manual build.xml has also changed.
In jbossdocs.xml I have to reference the _entity_ using full path

Because of these (ant 1.4 is beta and I did not check compliance with other
modules), I don't know if it is a good idea to commit now.
What do you think ?
Create a branch until it works ?

The problems I have now:
printable-html : Some javax.xml.transform.TransformerException when I added
more chapter xml files to jbossdocs.xml.
printable-html : the CSS is nt included in generated html.
printable-html : the file is jbossdocshtml (the . is missing)

html: it fails everytime with a javax.xml.transform.TransformerException:
java.lang.ArrayIndexOutOfBoundsException at the end of the build.


Vincent.


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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



[JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread Jason Dillon

Hello again, I am running into a problem with the latest JBossMQ wrt using
it to load balance across machines.

I have one machine which acts as a message router, running JBossMQ.  All
other machines use it for their JMSProvider.  When I have more than one MDB
attached to a single queue, and a user-thread adding messages over and over,
it looks like only one of the MDB's will ever read any messages.

I do not remember seeing this before.  It looks like when I startup a new
MDB that 50% of the time it will take over and the others will remain idle,
or it will simply never read any new messages.

I have each of these MDB setup with:

  MaximumSize1/MaximumSize
  MaxMessages1/MaxMessages

Which could be causing problem... but honestly I don't really know what
these two setting actually do.  I wanted to have these deployed MDB's to
only process one message at a time, which this seems to accomplish most of
the time.

Any ways, I am concerended about how JBossMQ is pushing messages over to
consumers.  I mentioned before that if one producer added 1k messages to a
queue, then one MDB was attached which would suck up all of the messages.
When a second MDB was attached it would not have anything todo.  Hiram
mentioned something about this, but I am not really sure what the plans were
to fix this.

I would like to get this fixed soon, as I am fairly dependent on this
behavior.

From my perspective, there are two major issues:

 1) JBossMQ does not seem to trade off between consumers (ie. round-robin or
whatever).

 2) JBossMQ does not have any configurable limits on how messages are pushed
from the server to clients/consumers.

I understand why JBossMQ wants to push over bulk messages to consumers, but
that is only really useful in some applications.  In my case, I would rather
that it pushed over smallers chunks (or even 1 msg at a time) to clients so
that I could utilize the cluster of machines that I have to distribute the
processing load.

So, to the JBossMQ folks, does this sound like it would be easy to
implement?  Do you have any suggestions on how it might be done (quick fix
and full blown god JMS provider version)?  I am willing to look into this
more, but I could use some pointers on which bits need to be tweaked.

Any ideas?

--jason


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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/jms ClusterTopicSession.java ClusterTopicSubscriber.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 16:16:18

  Modified:src/main/org/jboss/mq/cluster/jms ClusterTopicSession.java
ClusterTopicSubscriber.java
  Log:
   o removed org.jboss.mq.selectors.Selector from import, was not being used.
  
  Revision  ChangesPath
  1.3   +4 -3  
jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java
  
  Index: ClusterTopicSession.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ClusterTopicSession.java  2001/08/17 03:04:03 1.2
  +++ ClusterTopicSession.java  2001/08/21 23:16:18 1.3
  @@ -36,16 +36,17 @@
   import org.jboss.mq.SpyObjectMessage;
   import org.jboss.mq.SpyStreamMessage;
   import org.jboss.mq.SpyTextMessage;
  -import org.jboss.mq.selectors.Selector;
   
   /**
*  This class implements javax.jms.TopicSession
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
  -public class ClusterTopicSession implements TopicSession {
  +public class ClusterTopicSession
  +   implements TopicSession
  +{
  //MessageConsumers created by this session
  protected HashSet consumers = new HashSet();
   
  
  
  
  1.3   +5 -6  
jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSubscriber.java
  
  Index: ClusterTopicSubscriber.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSubscriber.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ClusterTopicSubscriber.java   2001/08/17 03:04:03 1.2
  +++ ClusterTopicSubscriber.java   2001/08/21 23:16:18 1.3
  @@ -16,17 +16,16 @@
   import org.jboss.mq.SpyMessage;
   import org.jboss.mq.cluster.transport.NodeId;
   
  -import org.jboss.mq.selectors.Selector;
  -
   /**
  - *  This class implements javax.jms.TopicSubscriber
  + * This class implements ttjavax.jms.TopicSubscriber/tt.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
  -public class ClusterTopicSubscriber implements TopicSubscriber {
  -
  +public class ClusterTopicSubscriber
  +   implements TopicSubscriber
  +{
  // The topic I registered
  Topictopic;
  //Am I closed ?
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyMessageConsumer.java SpyTopicSession.java SpyTopicSubscriber.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 16:16:17

  Modified:src/main/org/jboss/mq SpyMessageConsumer.java
SpyTopicSession.java SpyTopicSubscriber.java
  Log:
   o removed org.jboss.mq.selectors.Selector from import, was not being used.
  
  Revision  ChangesPath
  1.7   +5 -6  jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
  
  Index: SpyMessageConsumer.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- SpyMessageConsumer.java   2001/08/17 03:04:01 1.6
  +++ SpyMessageConsumer.java   2001/08/21 23:16:17 1.7
  @@ -16,19 +16,18 @@
   import javax.jms.MessageListener;
   import javax.jms.Session;
   
  -import org.jboss.mq.selectors.Selector;
  -
   /**
  - *  This class implements javax.jms.MessageConsumer
  + * This class implements ttjavax.jms.MessageConsumer/tt.
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.6 $
  + * @version$Revision: 1.7 $
*/
  -public class SpyMessageConsumer implements MessageConsumer, SpyConsumer, Runnable {
  -
  +public class SpyMessageConsumer
  +   implements MessageConsumer, SpyConsumer, Runnable
  +{
  //Link to my session
  public SpySession session;
  // The subscription structure should be fill out by the decendent
  
  
  
  1.3   +5 -6  jbossmq/src/main/org/jboss/mq/SpyTopicSession.java
  
  Index: SpyTopicSession.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTopicSession.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SpyTopicSession.java  2001/08/17 03:04:01 1.2
  +++ SpyTopicSession.java  2001/08/21 23:16:17 1.3
  @@ -24,20 +24,19 @@
   import javax.jms.TopicSubscriber;
   import javax.jms.XATopicSession;
   
  -import org.jboss.mq.selectors.Selector;
  -
   /**
  - *  This class implements javax.jms.TopicSession and javax.jms.XATopicSession
  + * This class implements ttjavax.jms.TopicSession/tt and
  + * ttjavax.jms.XATopicSession/tt.
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public class SpyTopicSession
  extends SpySession
  -   implements TopicSession, javax.jms.XATopicSession {
  -
  +   implements TopicSession, XATopicSession
  +{
  SpyTopicSession( Connection myConnection, boolean transacted, int 
acknowledgeMode ) {
 this( myConnection, transacted, acknowledgeMode, false );
  }
  
  
  
  1.3   +6 -6  jbossmq/src/main/org/jboss/mq/SpyTopicSubscriber.java
  
  Index: SpyTopicSubscriber.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTopicSubscriber.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SpyTopicSubscriber.java   2001/08/17 03:04:01 1.2
  +++ SpyTopicSubscriber.java   2001/08/21 23:16:17 1.3
  @@ -5,6 +5,7 @@
* See terms of license at gnu.org.
*/
   package org.jboss.mq;
  +
   import javax.jms.JMSException;
   import javax.jms.Message;
   import javax.jms.MessageListener;
  @@ -12,22 +13,21 @@
   
   import javax.jms.TopicSubscriber;
   
  -import org.jboss.mq.selectors.Selector;
  -
   /**
  - *  This class implements javax.jms.TopicSubscriber
  + * This class implements ttjavax.jms.TopicSubscriber/tt.
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public class SpyTopicSubscriber
  extends SpyMessageConsumer
  -   implements TopicSubscriber {
  +   implements TopicSubscriber
  +{
  // Attributes 
   
  -   //The topic I registered
  +   /** The registered topic. */
  private SpyTopic topic;
   
   
  
  
  

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



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

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 16:21:51

  Modified:src/main/org/jboss/mq Subscription.java
  Log:
   o changed comments to javadocs
  
  Revision  ChangesPath
  1.3   +32 -24jbossmq/src/main/org/jboss/mq/Subscription.java
  
  Index: Subscription.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/Subscription.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Subscription.java 2001/08/17 03:04:01 1.2
  +++ Subscription.java 2001/08/21 23:21:51 1.3
  @@ -8,63 +8,71 @@
   
   import java.io.Serializable;
   
  +import javax.jms.JMSException;
  +
   import org.jboss.mq.selectors.Selector;
   
   /**
  - *  This class contians all the data needed to for a the provider to to
  - *  determine if a message can be routed to a consumer.
  + * This class contains all the data needed to for a the provider to to
  + * determine if a message can be routed to a consumer.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public class Subscription
  -   implements Serializable {
  -   // This gets set to a unique value at the SpyConnection
  +   implements Serializable
  +{
  +   /** This gets set to a unique value at the SpyConnection. */
  public int   subscriptionId;
  -   // the queue we want to subscribe to
  +   
  +   /** The queue we want to subscribe to. */
  public SpyDestination destination;
  -   // the selector which will filter out messages
  +   
  +   /** The selector which will filter out messages. */
  public StringmessageSelector;
  -   // Should this message destroy the subscription?
  +   
  +   /** Should this message destroy the subscription? */
  public boolean   destroyDurableSubscription;
   
  -   // Topics might not want locally produced messages
  +   /** Topics might not want locally produced messages. */
  public boolean   noLocal;
   
  // Transient Values
  public transient Selector selector;
  public transient ConnectionToken dc;
  -   public transient Object clientConsumer = null;
  -
  -   // Determines the consumer would accept the message.
  -   public Selector getSelector()
  -  throws javax.jms.JMSException {
  +   public transient Object clientConsumer; // = null;
   
  -  if ( messageSelector == null ) {
  +   /**
  +* Determines the consumer would accept the message.
  +*/
  +   public Selector getSelector() throws JMSException {
  +  if (messageSelector == null) {
return null;
 }
   
  -  if ( selector == null ) {
  - selector = new Selector( messageSelector );
  +  if (selector == null) {
  + selector = new Selector(messageSelector);
 }
   
 return selector;
  }
   
  -   // Determines the consumer would accept the message.
  -   public boolean accepts( SpyMessage message )
  -  throws javax.jms.JMSException {
  -  if ( message.getJMSDestination() instanceof SpyTopic ) {
  +   /**
  +* Determines the consumer would accept the message.
  +*/
  +   public boolean accepts(SpyMessage message) throws JMSException {
  +  if (message.getJMSDestination() instanceof SpyTopic) {
// In the Topic case we allways deliver unless we have a noLocal
  - if ( noLocal  message.producerClientId.equals( dc.getClientID() ) ) {
  + if (noLocal  message.producerClientId.equals(dc.getClientID())) {
   return false;
}
 }
  +  
 Selector ms = getSelector();
  -  if ( ms != null ) {
  - if ( !ms.test( message ) ) {
  +  if (ms != null) {
  + if (!ms.test(message)) {
   return false;
}
 }
  
  
  

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



RE: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread David Maplesden

Hi Jason,

The way we implemented the message delivery this behaviour could happen, but
only when messages are arriving more slowly than they are being requested.  

This is because the set of receivers waiting for messages is a HashSet so
that if a receiver sends a request for a message more than once (which
happens when using a receive with a timeout) it won't get added more than
once.

What this means is that if you have multiple receivers waiting for a message
from a queue and a message arrives then it will be immediately delivered to
receiver A.  Receiver A is now removed from the HashSet, however if receiver
A finishes its processing and requests another message before another
message is sent to the queue it will be added back to the HashSet.  When the
next message arrives set will again be sent to receiver A because in the
HashSets ordering receiver A is clearly ahead of receiver B.

We didn't see any problem with this at the time, under heavy client
processing loads where messages are waiting on the queue as requests are
made then the messages will be shared out amongst the clients.  When there
is light loads then the messages will tend to be delivered to the same
client.  

We could implement an ordering on the server-side but I still don't know if
it is required.  Remember this only happens when your clients are going fast
enough that they actually have to wait for messages to arrive.  If messages
are being produced faster than the clients can process them then they will
be shared out amongst all the clients.

Cheers
David

 -Original Message-
 From: Jason Dillon [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, August 22, 2001 11:06 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] jbossmq  load balancing across vms
 
 
 Hello again, I am running into a problem with the latest 
 JBossMQ wrt using
 it to load balance across machines.
 
 I have one machine which acts as a message router, running 
 JBossMQ.  All
 other machines use it for their JMSProvider.  When I have 
 more than one MDB
 attached to a single queue, and a user-thread adding messages 
 over and over,
 it looks like only one of the MDB's will ever read any messages.
 
 I do not remember seeing this before.  It looks like when I 
 startup a new
 MDB that 50% of the time it will take over and the others 
 will remain idle,
 or it will simply never read any new messages.
 
 I have each of these MDB setup with:
 
   MaximumSize1/MaximumSize
   MaxMessages1/MaxMessages
 
 Which could be causing problem... but honestly I don't really 
 know what
 these two setting actually do.  I wanted to have these 
 deployed MDB's to
 only process one message at a time, which this seems to 
 accomplish most of
 the time.
 
 Any ways, I am concerended about how JBossMQ is pushing 
 messages over to
 consumers.  I mentioned before that if one producer added 1k 
 messages to a
 queue, then one MDB was attached which would suck up all of 
 the messages.
 When a second MDB was attached it would not have anything todo.  Hiram
 mentioned something about this, but I am not really sure what 
 the plans were
 to fix this.
 
 I would like to get this fixed soon, as I am fairly dependent on this
 behavior.
 
 From my perspective, there are two major issues:
 
  1) JBossMQ does not seem to trade off between consumers (ie. 
 round-robin or
 whatever).
 
  2) JBossMQ does not have any configurable limits on how 
 messages are pushed
 from the server to clients/consumers.
 
 I understand why JBossMQ wants to push over bulk messages to 
 consumers, but
 that is only really useful in some applications.  In my case, 
 I would rather
 that it pushed over smallers chunks (or even 1 msg at a time) 
 to clients so
 that I could utilize the cluster of machines that I have to 
 distribute the
 processing load.
 
 So, to the JBossMQ folks, does this sound like it would be easy to
 implement?  Do you have any suggestions on how it might be 
 done (quick fix
 and full blown god JMS provider version)?  I am willing to 
 look into this
 more, but I could use some pointers on which bits need to be tweaked.
 
 Any ideas?
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 

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



[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/jms JMSException.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 16:47:10

  Modified:src/main/javax/jms JMSException.java
  Log:
   o fixed setLinkedException sig to be serial compatible with JMS 1.0.2
 (needed to be synchronized and have its param name as 'ex' instead of
  'linkedException').
  
  Revision  ChangesPath
  1.2   +33 -29jboss-j2ee/src/main/javax/jms/JMSException.java
  
  Index: JMSException.java
  ===
  RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/jms/JMSException.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JMSException.java 2001/04/01 13:43:20 1.1
  +++ JMSException.java 2001/08/21 23:47:10 1.2
  @@ -10,24 +10,33 @@
   /**
 * This is the root class of all JMS exceptions. 
 * 
  -  * It provides following information: 
  -  * 
  +  * pIt provides following information: 
 * ul
  -  *   liprovider-specific string describing the error - This string is the 
standard Java exception message, and is available via getMessage(). 
  +  *   liprovider-specific string describing the error -
  +  *   This string is the standard Java exception message,
  +  *   and is available via getMessage(). 
 *   liprovider-specific, string error code 
  -  *   lireference to another exception - Often a JMS exception will be the result 
of a lower level problem. If appropriate, this lower level exception can be linked to 
the JMS exception. 
  +  *   lireference to another exception - Often a JMS exception will be
  +  *   the result of a lower level problem. If appropriate, this lower
  +  *   level exception can be linked to the JMS exception. 
 * /ul
 *
 * @author Chris Kimpton ([EMAIL PROTECTED])
  -  * @version $Revision: 1.1 $
  +  * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
  +  * @version $Revision: 1.2 $
**/
  -public class JMSException extends Exception
  +public class JMSException
  +   extends Exception
   {
  -   // CONSTRUCTORS -
  +   /** The specified error code */
  +   private String _errorCode; // = null;
   
  +   /** A linked exception */
  +   private Exception _linkedException;
  +   
  /** 
  - * Construct a JMSException with reason and error code for exception
  - */
  +* Construct a JMSException with reason and error code for exception
  +*/
  public JMSException(String reason, String errorCode)
  {
 super(reason);
  @@ -35,40 +44,35 @@
  }
   
  /** 
  - * Construct a JMSException with reason and with error code defaulting to null
  - */
  +* Construct a JMSException with reason and with error code defaulting
  +* to null.
  +*/
  public JMSException(String reason)
  {
  -  this(reason,null);
  +  this(reason, null);
  }
  -
  -   // PUBLIC METHODS -
   
  -   /** Get the vendor specific error code */
  +   /**
  +* Get the vendor specific error code.
  +*/
  public String getErrorCode()
  {
 return _errorCode;
  }
   
  -   /** Get the exception linked to this one.  
  - * ? who uses this ?
  - */
  +   /**
  +* Get the exception linked to this one.  
  +*/
  public Exception getLinkedException()
  {
 return _linkedException;
  }
   
  -   /** set the linked exception */
  -   public void setLinkedException(Exception linkedException)
  +   /**
  +* Set the linked exception
  +*/
  +   public synchronized void setLinkedException(Exception ex)
  {
  -  _linkedException = linkedException;
  +  _linkedException = ex;
  }
  -
  -   // ATTRIBUTES -
  -
  -   /** the specified error code */
  -   private String _errorCode = null;
  -
  -   /** a linked exception */
  -   private Exception _linkedException;
   }
  
  
  

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



[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/jms JMSException.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 16:51:22

  Modified:src/main/javax/jms JMSException.java
  Log:
   o needed to change field names too (removed leading _)
  
  Revision  ChangesPath
  1.3   +7 -7  jboss-j2ee/src/main/javax/jms/JMSException.java
  
  Index: JMSException.java
  ===
  RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/jms/JMSException.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMSException.java 2001/08/21 23:47:10 1.2
  +++ JMSException.java 2001/08/21 23:51:22 1.3
  @@ -23,16 +23,16 @@
 *
 * @author Chris Kimpton ([EMAIL PROTECTED])
 * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
  -  * @version $Revision: 1.2 $
  +  * @version $Revision: 1.3 $
**/
   public class JMSException
  extends Exception
   {
  /** The specified error code */
  -   private String _errorCode; // = null;
  +   private String errorCode; // = null;
   
  /** A linked exception */
  -   private Exception _linkedException;
  +   private Exception linkedException;
  
  /** 
   * Construct a JMSException with reason and error code for exception
  @@ -40,7 +40,7 @@
  public JMSException(String reason, String errorCode)
  {
 super(reason);
  -  _errorCode = errorCode;
  +  this.errorCode = errorCode;
  }
   
  /** 
  @@ -57,7 +57,7 @@
   */
  public String getErrorCode()
  {
  -  return _errorCode;
  +  return errorCode;
  }
   
  /**
  @@ -65,7 +65,7 @@
   */
  public Exception getLinkedException()
  {
  -  return _linkedException;
  +  return linkedException;
  }
   
  /**
  @@ -73,6 +73,6 @@
   */
  public synchronized void setLinkedException(Exception ex)
  {
  -  _linkedException = ex;
  +  linkedException = ex;
  }
   }
  
  
  

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



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

2001-08-21 Thread David Maplesden

  User: dmaplesden
  Date: 01/08/21 17:07:18

  Modified:src/main/org/jboss/mq SpyConnectionConsumer.java
  Log:
  Implement the loading of multiple messages into each session when under heavy load.
  
  Revision  ChangesPath
  1.5   +26 -9 jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java
  
  Index: SpyConnectionConsumer.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SpyConnectionConsumer.java2001/08/17 03:04:01 1.4
  +++ SpyConnectionConsumer.java2001/08/22 00:07:18 1.5
  @@ -19,7 +19,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
  - * @version$Revision: 1.4 $
  + * @version$Revision: 1.5 $
*/
   public class SpyConnectionConsumer implements javax.jms.ConnectionConsumer, 
SpyConsumer, Runnable {
   
  @@ -60,6 +60,8 @@
 this.destination = destination;
 this.serverSessionPool = serverSessionPool;
 this.maxMessages = maxMessages;
  +  if(this.maxMessages  1)
  + this.maxMessages = 1;
   
 subscription.destination = ( SpyDestination )destination;
 subscription.messageSelector = messageSelector;
  @@ -142,13 +144,24 @@
   
  //Used to facilitate delivery of messages to sessions from server session pool.
  public void run() {
  -  SpyMessage mes = null;
  +  java.util.ArrayList mesList = new java.util.ArrayList();
 try {
outer :
while ( true ) {
  -//get Message
  -while ( mes == null ) {
  -   mes = connection.receive( subscription, 0 );
  +synchronized( queue ){
  +   if(closed)
  +  break outer;
  +}
  +//get Messages
  +for(int i=0;imaxMessages;i++){
  +   SpyMessage mes = connection.receive(subscription, -1); //receive no 
wait
  +   if(mes == null)
  +  break;
  +   else
  +  mesList.add(mes);
  +}
  +if(mesList.isEmpty()){
  +   SpyMessage mes = connection.receive( subscription, 0 );
  if ( mes == null ) {
 synchronized ( queue ) {
waitingForMessage = true;
  @@ -166,7 +179,9 @@
waitingForMessage = false;
 }
  }
  +   mesList.add(mes);
   }
  +
   ServerSession serverSession = serverSessionPool.getServerSession();
   SpySession spySession = ( SpySession )serverSession.getSession();
   
  @@ -176,17 +191,19 @@
  spySession.sessionConsumer.subscription = subscription;
   }
   
  -spySession.addMessage( mes );
  +for(int i=0;imesList.size();i++){
  +   spySession.addMessage( (SpyMessage)mesList.get(i) );
  +}
   
   cat.debug(  + this +  Starting the ServerSession. );
   serverSession.start();
  -mes = null;
  +mesList.clear();
}
 } catch ( JMSException e ) {
cat.warn( Connection consumer closing due to error in listening thread., 
e );
try {
  -if ( mes != null ) {
  -   connection.send( mes.getAcknowledgementRequest( false ) );
  +for(int i=0;imesList.size();i++){
  +   connection.send( 
((SpyMessage)mesList.get(i)).getAcknowledgementRequest( false ) );
   }
   close();
} catch ( Exception ignore ) {
  
  
  

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



Re: [JBoss-dev] manual build

2001-08-21 Thread David Jencks

Interesting, today I worked on the manual build also.  I have it working
with jdk 1.3.1, ant 1.3, some updated xml jars.

problems I still have:

html files end up in manual instead of manual/output/html

jbossjms.xml has a syntax error.

Problems I fixed:

build.sh does not set ANT_HOME correctly, so the script uses a system ant
instead of the one in jboss.

XSLTransform, in ant.jar, uses several classes from Optional.jar, so
build.sh also has to include optional.jar on the local classpath.

The xml processor files in tools... are out of date versions.

I hope to get the output directory fixed shortly, probably the syntax error
will be easy too.

Since mine works with ant 1.3 should I commit? or should we be forward
looking?

david jencks

On 2001.08.21 18:56:25 -0400 Vincent Harcq wrote:
 Hi,
 Is there anybody trying to make the manual build run correctly?
 
 I give it a (painful) try.
 I succeed to build a part of html and printable-html (hum simply the
 preface,intro, cmp and jaws for the moment)
 
 I choose to move to ant 1.4 that use JAXP 1.1 to avoid problems with
 style,
 xsl, ...
 I needed to change the jboss-all/build/build.bat to include sun/jaxp and
 ant/lib/ext jars.
 The manual build.xml has also changed.
 In jbossdocs.xml I have to reference the _entity_ using full path
 
 Because of these (ant 1.4 is beta and I did not check compliance with
 other
 modules), I don't know if it is a good idea to commit now.
 What do you think ?
 Create a branch until it works ?
 
 The problems I have now:
 printable-html : Some javax.xml.transform.TransformerException when I
 added
 more chapter xml files to jbossdocs.xml.
 printable-html : the CSS is nt included in generated html.
 printable-html : the file is jbossdocshtml (the . is missing)
 
 html: it fails everytime with a javax.xml.transform.TransformerException:
 java.lang.ArrayIndexOutOfBoundsException at the end of the build.
 
 
 Vincent.
 
 
 _
 Do You Yahoo!?
 Get your free @yahoo.com address at http://mail.yahoo.com
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



Re: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread David Jencks

I am not an expert Is this sharing of a message queue receiving end
really spec compliant?  How does it relate to order-of-messages guarantees?
It seems to me this may be the conceptual difference between message queues
and javaspaces..??

david jencks

On 2001.08.21 19:06:08 -0400 Jason Dillon wrote:
 Hello again, I am running into a problem with the latest JBossMQ wrt
 using
 it to load balance across machines.
 
 I have one machine which acts as a message router, running JBossMQ.  All
 other machines use it for their JMSProvider.  When I have more than one
 MDB
 attached to a single queue, and a user-thread adding messages over and
 over,
 it looks like only one of the MDB's will ever read any messages.
 
 I do not remember seeing this before.  It looks like when I startup a new
 MDB that 50% of the time it will take over and the others will remain
 idle,
 or it will simply never read any new messages.
 
 I have each of these MDB setup with:
 
   MaximumSize1/MaximumSize
   MaxMessages1/MaxMessages
 
 Which could be causing problem... but honestly I don't really know what
 these two setting actually do.  I wanted to have these deployed MDB's to
 only process one message at a time, which this seems to accomplish most
 of
 the time.
 
 Any ways, I am concerended about how JBossMQ is pushing messages over to
 consumers.  I mentioned before that if one producer added 1k messages to
 a
 queue, then one MDB was attached which would suck up all of the messages.
 When a second MDB was attached it would not have anything todo.  Hiram
 mentioned something about this, but I am not really sure what the plans
 were
 to fix this.
 
 I would like to get this fixed soon, as I am fairly dependent on this
 behavior.
 
 From my perspective, there are two major issues:
 
  1) JBossMQ does not seem to trade off between consumers (ie. round-robin
 or
 whatever).
 
  2) JBossMQ does not have any configurable limits on how messages are
 pushed
 from the server to clients/consumers.
 
 I understand why JBossMQ wants to push over bulk messages to consumers,
 but
 that is only really useful in some applications.  In my case, I would
 rather
 that it pushed over smallers chunks (or even 1 msg at a time) to clients
 so
 that I could utilize the cluster of machines that I have to distribute
 the
 processing load.
 
 So, to the JBossMQ folks, does this sound like it would be easy to
 implement?  Do you have any suggestions on how it might be done (quick
 fix
 and full blown god JMS provider version)?  I am willing to look into this
 more, but I could use some pointers on which bits need to be tweaked.
 
 Any ideas?
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



[JBoss-dev] jbossmq selector parser grammer source

2001-08-21 Thread Jason Dillon

Where is the source for the selector parser?  It looks like it is not
parsing the literals true and false, it only looks for TRUE and
FALSE.

I am contemplating modifiying parser.java int yylex() under the //CST group
group, but I would rather modify the grammer source and regenerate the
parser.

Perhaps we could switch this to javacc and let ant build the parser as part
of the build.

It looks like there might be a problem with Operator.equal() too, which I am
looking into now...  Yup, sure is.  Operator.equal() does not properly
handle Boolean types.

I have just fixed (and verified) both of these problems.  Should I commit
them?  Silly me, of course I should commit them... but where is jms.y?  When
ever the parser is regenerated from this it will blow away these changes.

Can someone change this to javacc, check in the source grammer and setup the
build system to automatically generate this?

--jason


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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors Operator.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 17:44:44

  Modified:src/main/org/jboss/mq/selectors Operator.java
  Log:
   o Operator.equal() will properly compute the equality when using Boolean
 types.
  
  Revision  ChangesPath
  1.3   +3 -1  jbossmq/src/main/org/jboss/mq/selectors/Operator.java
  
  Index: Operator.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Operator.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Operator.java 2001/08/17 03:04:06 1.2
  +++ Operator.java 2001/08/22 00:44:44 1.3
  @@ -14,7 +14,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
   public class Operator {
  int  operation;
  @@ -183,7 +183,9 @@
case STRING:
case LONG:
case DOUBLE:
  + case BOOLEAN:
   computeArgument2();
  +
   if ( arg2 == null ) {
  return Boolean.FALSE;
   }
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors parser.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 17:52:31

  Modified:src/main/org/jboss/mq/selectors parser.java
  Log:
   o Added support for the true and false boolean literals.
  
  Revision  ChangesPath
  1.3   +2 -2  jbossmq/src/main/org/jboss/mq/selectors/parser.java
  
  Index: parser.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/parser.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- parser.java   2001/08/17 03:04:06 1.2
  +++ parser.java   2001/08/22 00:52:31 1.3
  @@ -540,11 +540,11 @@
 }
   
 //CST group
  -  if ( s.equals( TRUE ) ) {
  +  if ( s.equals( TRUE ) || s.equals(true) ) {
yylval = new parserval( ( Object )Boolean.TRUE );
return CST;
 }
  -  if ( s.equals( FALSE ) ) {
  +  if ( s.equals( FALSE ) || s.equals(false) ) {
yylval = new parserval( ( Object )Boolean.FALSE );
return CST;
 }
  
  
  

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



[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors Selector.java

2001-08-21 Thread Jason Dillon

  User: user57  
  Date: 01/08/21 17:53:35

  Modified:src/main/org/jboss/mq/selectors Selector.java
  Log:
   o added some commented logging (too verbose to leave it for now)
   o changed exceptions to return a bit more detail
  
  Revision  ChangesPath
  1.3   +105 -62   jbossmq/src/main/org/jboss/mq/selectors/Selector.java
  
  Index: Selector.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Selector.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Selector.java 2001/08/17 03:04:06 1.2
  +++ Selector.java 2001/08/22 00:53:35 1.3
  @@ -8,10 +8,12 @@
   
   import java.util.HashMap;
   import java.util.Iterator;
  -import javax.jms.InvalidSelectorException;
   
  +import javax.jms.InvalidSelectorException;
   import javax.jms.JMSException;
   
  +import org.apache.log4j.Category;
  +
   import org.jboss.mq.SpyMessage;
   
   /**
  @@ -19,112 +21,153 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Juha Lindfors ([EMAIL PROTECTED])
  + * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @createdAugust 16, 2001
  - * @version$Revision: 1.2 $
  + * @version$Revision: 1.3 $
*/
  -public class Selector {
  -   public HashMap   identifiers;
  -   // HashMap of Identifiers
  -   public Objectresult;
  +public class Selector
  +{
  +   public HashMap identifiers;
  +   public Object result;
  +   private Class resultType;
  +   
  +   static Category cat = Category.getInstance(Selector.class);
   
  -   static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance( 
Selector.class );
  -
  -   public Selector( String sel )
  -  throws JMSException {
  +   public Selector(String sel) throws JMSException {
 parser bob = new parser();
 identifiers = new HashMap();
   
 try {
  - result = bob.parse( sel, identifiers );
  -  } catch ( Exception e ) {
  - InvalidSelectorException exception = new InvalidSelectorException( The 
selector is invalid. );
  - exception.setLinkedException( e );
  + result = bob.parse(sel, identifiers);
  + resultType = result.getClass();
  +  }
  +  catch (Exception e) {
  + InvalidSelectorException exception =
  +new InvalidSelectorException(The selector is invalid.);
  + exception.setLinkedException(e);
throw exception;
 }
   
  -  //Log.notice(result.toString());
  +//   if (cat.isDebugEnabled()) {
  +//  cat.debug(result:  + resultType +  =  + result);
  +//   }
  }
  -
  -   public boolean test( SpyMessage mes )
  -  throws JMSException {
   
  +   public boolean test(SpyMessage mes) throws JMSException {
 try {
  -
  - //Set the identifiers values
  + // Set the identifiers values
Iterator i = identifiers.values().iterator();
  -
  - while ( i.hasNext() ) {
  -Identifier id = ( Identifier )i.next();
   
  -Object find = mes.getObjectProperty( id.name );
  + while (i.hasNext()) {
  +Identifier id = (Identifier)i.next();
  +Object find = mes.getObjectProperty(id.name);
  +// if (cat.isDebugEnabled()) {
  +//cat.debug(Identifier:  + id);
  +//cat.debug(Property:  + find);
  +//if (find != null) {
  +//   cat.debug(Property type:  + find.getClass());
  +//}
  +// }
   
  -if ( find == null ) {
  -   find = getHeaderFieldReferences( mes, id.name );
  +if (find == null) {
  +   find = getHeaderFieldReferences(mes, id.name);
   }
   
  -if ( find == null ) {
  -   cat.debug( Warning : missing property  + id.name );
  +if (find == null) {
  +   if (cat.isDebugEnabled()) {
  +  cat.debug(Warning : missing property  + id.name);
  +   }
  id.value = null;
  -} else {
  +}
  +else {
  Class type = find.getClass();
  -   if ( type.equals( Boolean.class ) || type.equals( String.class )
  -  || type.equals( Double.class ) || type.equals( Float.class )
  -  || type.equals( Integer.class ) || type.equals( Long.class )
  -  || type.equals( Short.class ) || type.equals( Byte.class ) ) {
  +   if (type.equals(Boolean.class) ||
  +   type.equals(String.class)  ||
  +   type.equals(Double.class)  ||
  +   type.equals(Float.class)   ||
  +   type.equals(Integer.class) ||
  +   type.equals(Long.class)||
  +   type.equals(Short.class)   

Re: [JBoss-dev] manual build

2001-08-21 Thread Jason Dillon

What xml jars did you have to update?  Where did you update them?

 XSLTransform, in ant.jar, uses several classes from Optional.jar, so
 build.sh also has to include optional.jar on the local classpath.

By adding optional.jar to the system classpath, all support jars will also
have to be on the local classpath, which means that users will either have
to use a custom ant, which contains all the correct bits in $ANT_HOME/lib or
they will have to install the required versions of those jars into their
$ANT_HOME/lib or the build system will not work.

This is a rather huge problem with Ant 1.3 and how it loads classes.  The
easiest thing todo is insist that all users use the
tools/apache/ant/bin/ant* to start the build (via build.* scripts) or they
can update there own ANT_HOME to include all of the jars from
tools/apache/ant/lib into their $ANT_HOME/lib.

I origionally had things setup to use a version of ant with the correct
libs, but reverted to the current style to allow people to run any standard
ant dist directly.

Unfortunatly the optional.jar makes this whole thing a huge mess.  I do not
have a good fix for this at the moment.  Does anyone know if 1.4 fixes this
crappy class loading problem?

 The xml processor files in tools... are out of date versions.

True, but they are from the ant 1.3 dist, so if we expect users to run a
vanilla ant and get it to work, we have to use these.

 Since mine works with ant 1.3 should I commit? or should we be forward
 looking?

I think we need to get an answer about how 1.4 might fix this and allow
users to still use `ant` directly, or if that requirement is causing more
problems than it solves.

--jason


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



Re: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread Jason Dillon

It does not say... this is one of the grey-areas of the spec.  Most
providers will round-robin over multipule recievers.  It is really too bad
that this is not more concreate, as JMS would provide a nice mech. for
distributing over a large group of machines, and allow for ordering and
such.

I think that I will probably drop JMS for this as soon as I have time to
rearch. under a different distribution system (like JavaSpaces).  JMS is too
ugly and too vendor specific.  I will probably still keep it around for
async events from beans/to beans though.  Just not as the backend for
distributing load.

--jason


On Tue, 21 Aug 2001, David Jencks wrote:

 I am not an expert Is this sharing of a message queue receiving end
 really spec compliant?  How does it relate to order-of-messages guarantees?
 It seems to me this may be the conceptual difference between message queues
 and javaspaces..??

 david jencks

 On 2001.08.21 19:06:08 -0400 Jason Dillon wrote:
  Hello again, I am running into a problem with the latest JBossMQ wrt
  using
  it to load balance across machines.
 
  I have one machine which acts as a message router, running JBossMQ.  All
  other machines use it for their JMSProvider.  When I have more than one
  MDB
  attached to a single queue, and a user-thread adding messages over and
  over,
  it looks like only one of the MDB's will ever read any messages.
 
  I do not remember seeing this before.  It looks like when I startup a new
  MDB that 50% of the time it will take over and the others will remain
  idle,
  or it will simply never read any new messages.
 
  I have each of these MDB setup with:
 
MaximumSize1/MaximumSize
MaxMessages1/MaxMessages
 
  Which could be causing problem... but honestly I don't really know what
  these two setting actually do.  I wanted to have these deployed MDB's to
  only process one message at a time, which this seems to accomplish most
  of
  the time.
 
  Any ways, I am concerended about how JBossMQ is pushing messages over to
  consumers.  I mentioned before that if one producer added 1k messages to
  a
  queue, then one MDB was attached which would suck up all of the messages.
  When a second MDB was attached it would not have anything todo.  Hiram
  mentioned something about this, but I am not really sure what the plans
  were
  to fix this.
 
  I would like to get this fixed soon, as I am fairly dependent on this
  behavior.
 
  From my perspective, there are two major issues:
 
   1) JBossMQ does not seem to trade off between consumers (ie. round-robin
  or
  whatever).
 
   2) JBossMQ does not have any configurable limits on how messages are
  pushed
  from the server to clients/consumers.
 
  I understand why JBossMQ wants to push over bulk messages to consumers,
  but
  that is only really useful in some applications.  In my case, I would
  rather
  that it pushed over smallers chunks (or even 1 msg at a time) to clients
  so
  that I could utilize the cluster of machines that I have to distribute
  the
  processing load.
 
  So, to the JBossMQ folks, does this sound like it would be easy to
  implement?  Do you have any suggestions on how it might be done (quick
  fix
  and full blown god JMS provider version)?  I am willing to look into this
  more, but I could use some pointers on which bits need to be tweaked.
 
  Any ideas?
 
  --jason
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



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



RE: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread David Maplesden

I'm not up-to-date on javaspaces but with jms you can certainly have
multiple receivers on the same message queue, you can also have multiple
senders.  The JMS spec does not specify any policy for how messages are
distributed between different receivers though.  

As for message order, it is only guaranteed amongst messages sent to the
same queue from the same sender, that is if you receive two messages from
the same queue sent by the same sender they will arrive in the order sent
(except for some cases involving different priorities and the like).

Cheers,
David

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, August 22, 2001 12:48 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] jbossmq  load balancing across vms
 
 
 I am not an expert Is this sharing of a message queue 
 receiving end
 really spec compliant?  How does it relate to 
 order-of-messages guarantees?
 It seems to me this may be the conceptual difference between 
 message queues
 and javaspaces..??
 
 david jencks
 
 On 2001.08.21 19:06:08 -0400 Jason Dillon wrote:
  Hello again, I am running into a problem with the latest JBossMQ wrt
  using
  it to load balance across machines.
  
  I have one machine which acts as a message router, running 
 JBossMQ.  All
  other machines use it for their JMSProvider.  When I have 
 more than one
  MDB
  attached to a single queue, and a user-thread adding 
 messages over and
  over,
  it looks like only one of the MDB's will ever read any messages.
  
  I do not remember seeing this before.  It looks like when I 
 startup a new
  MDB that 50% of the time it will take over and the others 
 will remain
  idle,
  or it will simply never read any new messages.
  
  I have each of these MDB setup with:
  
MaximumSize1/MaximumSize
MaxMessages1/MaxMessages
  
  Which could be causing problem... but honestly I don't 
 really know what
  these two setting actually do.  I wanted to have these 
 deployed MDB's to
  only process one message at a time, which this seems to 
 accomplish most
  of
  the time.
  
  Any ways, I am concerended about how JBossMQ is pushing 
 messages over to
  consumers.  I mentioned before that if one producer added 
 1k messages to
  a
  queue, then one MDB was attached which would suck up all of 
 the messages.
  When a second MDB was attached it would not have anything 
 todo.  Hiram
  mentioned something about this, but I am not really sure 
 what the plans
  were
  to fix this.
  
  I would like to get this fixed soon, as I am fairly 
 dependent on this
  behavior.
  
  From my perspective, there are two major issues:
  
   1) JBossMQ does not seem to trade off between consumers 
 (ie. round-robin
  or
  whatever).
  
   2) JBossMQ does not have any configurable limits on how 
 messages are
  pushed
  from the server to clients/consumers.
  
  I understand why JBossMQ wants to push over bulk messages 
 to consumers,
  but
  that is only really useful in some applications.  In my 
 case, I would
  rather
  that it pushed over smallers chunks (or even 1 msg at a 
 time) to clients
  so
  that I could utilize the cluster of machines that I have to 
 distribute
  the
  processing load.
  
  So, to the JBossMQ folks, does this sound like it would be easy to
  implement?  Do you have any suggestions on how it might be 
 done (quick
  fix
  and full blown god JMS provider version)?  I am willing to 
 look into this
  more, but I could use some pointers on which bits need to 
 be tweaked.
  
  Any ideas?
  
  --jason
  
  
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 

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



[JBoss-dev] [ jboss-Change Notes-454045 ] JBossMQ message selector fix

2001-08-21 Thread noreply

Change Notes item #454045, was opened at 2001-08-21 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=381174aid=454045group_id=22866

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Jason Dillon (user57)
Assigned to: Nobody/Anonymous (nobody)
Summary: JBossMQ message selector fix

Initial Comment:
The JBossMQ message selector parser will now allow the
boolean literals true and false as well as TRUE
and FALSE.

Equality operators can now be used on Boolean
properties values too.  For example, if a boolean
property is set on a message:

msg.setBooleanProperty(myProperty, true);

The following message selector will function correctly:

myProperty = true

or

myProperty = TRUE



--

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

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



RE: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread Jason Dillon

 What this means is that if you have multiple receivers waiting for a message
 from a queue and a message arrives then it will be immediately delivered to
 receiver A.  Receiver A is now removed from the HashSet, however if receiver
 A finishes its processing and requests another message before another
 message is sent to the queue it will be added back to the HashSet.  When the
 next message arrives set will again be sent to receiver A because in the
 HashSets ordering receiver A is clearly ahead of receiver B.

Why a HashSet and not a LinkedList?

--jason


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



Re: [JBoss-dev] manual build

2001-08-21 Thread David Jencks

On 2001.08.21 21:07:53 -0400 Jason Dillon wrote:
 What xml jars did you have to update?  Where did you update them?

I'll get back to you on that- mostly remove parser.jar and include
xalan/xerces from previous manual build.
 
  XSLTransform, in ant.jar, uses several classes from Optional.jar, so
  build.sh also has to include optional.jar on the local classpath.
 
 By adding optional.jar to the system classpath, all support jars will
 also
 have to be on the local classpath, which means that users will either
 have
 to use a custom ant, which contains all the correct bits in $ANT_HOME/lib
 or
 they will have to install the required versions of those jars into their
 $ANT_HOME/lib or the build system will not work.

Well, after making search set ANT_HOME instead of ANT, so the result is
useful, I put this at the end of build.sh and the manual builds more or
less


echo ant_home is $ANT_HOME
#kill preexisting classpath, we want our just found ant.
CLASSPATH=

#for manual only, include optional.jar on classpath- lousy ant style
task
#design has XSLProcess in ant.jar and loaded classes in optional.jar!!!
CLASSPATH=$ANT_HOME/lib/ext/optional.jar

export ANT ANT_HOME CLASSPATH
exec $ANT $ANT_OPTIONS $@
}

##
## Bootstrap
##

main $@


the ant script takes care of adding ant.jar to the classpath.

I'm a little confused.  Are you intentionally including an ant distro in
jboss yet having the build.sh scripts not find it?  It seems to me that the
jboss build system, since it includes a copy of ant, should use that copy
by default, and find it properly.

david jencks

ps.

here's my change to search:

search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
if [ -x $ANT ]; then
# found one
#this is return value of function!
echo $ANT_HOME
break
fi
done
}


Returning ANT_HOME lets ANT_HOME be set, and ANT can be defined from it. 
Returning ANT, as in cvs, seems to be useless -- ANT_HOME is never set, so
the ANT just set can't be found.  At any rate this seemed to be what was
happening on my system.

 
 This is a rather huge problem with Ant 1.3 and how it loads classes.  The
 easiest thing todo is insist that all users use the
 tools/apache/ant/bin/ant* to start the build (via build.* scripts) or
 they
 can update there own ANT_HOME to include all of the jars from
 tools/apache/ant/lib into their $ANT_HOME/lib.
 
 I origionally had things setup to use a version of ant with the correct
 libs, but reverted to the current style to allow people to run any
 standard
 ant dist directly.
 
 Unfortunatly the optional.jar makes this whole thing a huge mess.  I do
 not
 have a good fix for this at the moment.  Does anyone know if 1.4 fixes
 this
 crappy class loading problem?
 
  The xml processor files in tools... are out of date versions.
 
 True, but they are from the ant 1.3 dist, so if we expect users to run a
 vanilla ant and get it to work, we have to use these.
 
  Since mine works with ant 1.3 should I commit? or should we be forward
  looking?
 
 I think we need to get an answer about how 1.4 might fix this and allow
 users to still use `ant` directly, or if that requirement is causing more
 problems than it solves.
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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



RE: [JBoss-dev] jbossmq load balancing across vms

2001-08-21 Thread David Maplesden

Basically because of efficiency.

Because the possibility exists that when a receive is done the receiver may
already be in the list of receivers (due to receives with timeouts) we have
to check that a receiver is not already in the list before adding them to
the list.  This search O(n) for a LinkedList and constant time for a
HashSet.

If you are absolutely desparate for the round-robin allocation of messages
then I would re-implement keeping both the LinkedList and the HashSet.  Use
the HashSet to check if the receiver is already receiving and the LinkedList
to maintain the order of the requests.

The code I am talking about is the org.jboss.mq.server.BasicQueue class.

Cheers,
David.

 -Original Message-
 From: Jason Dillon [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, August 22, 2001 1:50 PM
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] jbossmq  load balancing across vms
 
 
  What this means is that if you have multiple receivers 
 waiting for a message
  from a queue and a message arrives then it will be 
 immediately delivered to
  receiver A.  Receiver A is now removed from the HashSet, 
 however if receiver
  A finishes its processing and requests another message 
 before another
  message is sent to the queue it will be added back to the 
 HashSet.  When the
  next message arrives set will again be sent to receiver A 
 because in the
  HashSets ordering receiver A is clearly ahead of receiver B.
 
 Why a HashSet and not a LinkedList?
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development
 

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



RE: [JBoss-dev] manual build

2001-08-21 Thread Vincent Harcq

Hi,

 Interesting, today I worked on the manual build also.  I have it working
 with jdk 1.3.1, ant 1.3, some updated xml jars.

 problems I still have:

 html files end up in manual instead of manual/output/html
I had to change the copy todir task and some others as well.
If you run one by one (html only or printablehtml only), it simpler to see
where the html are generated.


 jbossjms.xml has a syntax error.

 Problems I fixed:

 build.sh does not set ANT_HOME correctly, so the script uses a system ant
 instead of the one in jboss.

 XSLTransform, in ant.jar, uses several classes from Optional.jar, so
 build.sh also has to include optional.jar on the local classpath.

 The xml processor files in tools... are out of date versions.

That's the reason why I switched to 1.4.
My build (.bat) is doing :

for %%i in (..\thirdparty\sun\jaxp\lib\*.jar) do call lcp.bat %%i
for %%i in (..\tools\apache\ant\lib\*.jar) do call lcp.bat %%i
for %%i in (..\tools\apache\ant\lib\ext\*.jar) do call lcp.bat %%i

With no more xml jars in ant\lib\


 I hope to get the output directory fixed shortly, probably the
 syntax error
 will be easy too.

 Since mine works with ant 1.3 should I commit? or should we be forward
 looking?

 david jencks

 On 2001.08.21 18:56:25 -0400 Vincent Harcq wrote:
  Hi,
  Is there anybody trying to make the manual build run correctly?
 
  I give it a (painful) try.
  I succeed to build a part of html and printable-html (hum simply the
  preface,intro, cmp and jaws for the moment)
 
  I choose to move to ant 1.4 that use JAXP 1.1 to avoid problems with
  style,
  xsl, ...
  I needed to change the jboss-all/build/build.bat to include sun/jaxp and
  ant/lib/ext jars.
  The manual build.xml has also changed.
  In jbossdocs.xml I have to reference the _entity_ using full path
 
  Because of these (ant 1.4 is beta and I did not check compliance with
  other
  modules), I don't know if it is a good idea to commit now.
  What do you think ?
  Create a branch until it works ?
 
  The problems I have now:
  printable-html : Some javax.xml.transform.TransformerException when I
  added
  more chapter xml files to jbossdocs.xml.
  printable-html : the CSS is nt included in generated html.
  printable-html : the file is jbossdocshtml (the . is missing)
 
  html: it fails everytime with a
 javax.xml.transform.TransformerException:
  java.lang.ArrayIndexOutOfBoundsException at the end of the build.
 
 
  Vincent.
 
 
  _
  Do You Yahoo!?
  Get your free @yahoo.com address at http://mail.yahoo.com
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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