[JBoss-dev] php5 is coming

2003-03-29 Thread julien viet
have a look at the new php 5 :  http://talks.php.net

they added : exceptions, modifiers, interfaces, abstract, namespaces  and more.
it's mono powered.

it seems that now they want to reach enterprise level and have
to get more credibility for that.

julien



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] php5 is coming

2003-03-29 Thread julien viet
sorry I gave a wrong link :

 http://talks.php.net/show/php5intro
 
 
jv have a look at the new php 5 :  http://talks.php.net

jv they added : exceptions, modifiers, interfaces, abstract, namespaces  and more.
jv it's mono powered.

jv it seems that now they want to reach enterprise level and have
jv to get more credibility for that.

jv julien



jv ---
jv This SF.net email is sponsored by:
jv The Definitive IT and Networking Event. Be There!
jv NetWorld+Interop Las Vegas 2003 -- Register today!
jv http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
jv ___
jv Jboss-development mailing list
jv [EMAIL PROTECTED]
jv https://lists.sourceforge.net/lists/listinfo/jboss-development



-- 
Best regards,
 julienmailto:[EMAIL PROTECTED]



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread Thomas Peuss
Hello!

I need a thread pool to simplify my code for the HTTP-loadbalancer.
Is there a generic ThreadPool in JBoss-code (HEAD)?
Any hints welcome

CU
Thomas


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread David Jencks
There is the jca 1.5 thread pool, BaseWorkManager. It is a simple
implementation of the j2ee 1.4 official thread pool. If this provides more
than you want to deal with, lets discuss design.

david jencks

On 2003.03.29 09:04 Thomas Peuss wrote:
 Hello!
 
 I need a thread pool to simplify my code for the HTTP-loadbalancer.
 Is there a generic ThreadPool in JBoss-code (HEAD)?
 
 Any hints welcome
 
 CU
 Thomas
 
 
 
 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] hsqldb options

2003-03-29 Thread David Jencks
Prompted by a customer, I did some experiments with hsqldb options.

Currently we specify a tcp port and require a hsqldb mbean to start the
hsqldb server.  This opens a port and requires explicit hsqldb shutdown.

Two other options that appear to work are:

specify url jdbc:hsqldb:. and remove the hsqldb mbean.  This results in a
totally in memory db, nothing saved to disk.  IMO this is appropriate for
most of the testsuite since it eliminates problems with data not being
cleaned  up between test runs.

specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.  This results
in the db saved in a couple of files named like somefile.  No port is
opened.  No explicit shutdown of hsqldb  seems to be required (although I
didn't test how much data is actually saved)

Could someone who knows more about hsqldb  please explain clearly why we
would want to continue using the setup we  have now rather than one of the
tcp-port free options?

Thanks
david jencks


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread Bela Ban
Thomas Peuss wrote:

Hello!

I need a thread pool to simplify my code for the HTTP-loadbalancer.
Is there a generic ThreadPool in JBoss-code (HEAD)? 


I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called 
PooledExecutor). It will be part of JDK 1.5 (Tiger).

--
Bela Ban
www.javagroups.com
(408) 316-4459


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Micael
There is no good reason.

At 10:55 AM 3/29/03 -0500, you wrote:
Prompted by a customer, I did some experiments with hsqldb options.

Currently we specify a tcp port and require a hsqldb mbean to start the
hsqldb server.  This opens a port and requires explicit hsqldb shutdown.
Two other options that appear to work are:

specify url jdbc:hsqldb:. and remove the hsqldb mbean.  This results in a
totally in memory db, nothing saved to disk.  IMO this is appropriate for
most of the testsuite since it eliminates problems with data not being
cleaned  up between test runs.
specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.  This results
in the db saved in a couple of files named like somefile.  No port is
opened.  No explicit shutdown of hsqldb  seems to be required (although I
didn't test how much data is actually saved)
Could someone who knows more about hsqldb  please explain clearly why we
would want to continue using the setup we  have now rather than one of the
tcp-port free options?
Thanks
david jencks
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


LEGAL NOTICE

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank 
you  



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread Scott M Stark
The thread pool needs to be a true mbean service with stats and its configuration
exposed via JMX, not just a class. The JCA api and associated component David
mentioned should be a good start for such a service.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Bela Ban [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 7:59 AM
Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss?


 Thomas Peuss wrote:
 
  Hello!
 
  I need a thread pool to simplify my code for the HTTP-loadbalancer.
  Is there a generic ThreadPool in JBoss-code (HEAD)? 
 
 
 I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called 
 PooledExecutor). It will be part of JDK 1.5 (Tiger).
 
 
 -- 
 Bela Ban
 www.javagroups.com
 (408) 316-4459



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] !

2003-03-29 Thread shyu




 
 

 


 


  [] 
[] [] [] [] [] [] [] 
   






* 

* 

* 


95206
(0571) 86465080 86467128 86455732  
(0571)86469732
 13958106746 E_mail[EMAIL PROTECTED] 

www.hzefu.com www.hzefu.net www.hzefu.cn 
 QQ965301




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Scott M Stark
There is no reason why we can't just document both configs and let the user
choose what they want. The pure in memory version seems like the better
default configuration.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 7:55 AM
Subject: [JBoss-dev] hsqldb options


 Prompted by a customer, I did some experiments with hsqldb options.
 
 Currently we specify a tcp port and require a hsqldb mbean to start the
 hsqldb server.  This opens a port and requires explicit hsqldb shutdown.
 
 Two other options that appear to work are:
 
 specify url jdbc:hsqldb:. and remove the hsqldb mbean.  This results in a
 totally in memory db, nothing saved to disk.  IMO this is appropriate for
 most of the testsuite since it eliminates problems with data not being
 cleaned  up between test runs.
 
 specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.  This results
 in the db saved in a couple of files named like somefile.  No port is
 opened.  No explicit shutdown of hsqldb  seems to be required (although I
 didn't test how much data is actually saved)
 
 Could someone who knows more about hsqldb  please explain clearly why we
 would want to continue using the setup we  have now rather than one of the
 tcp-port free options?
 
 Thanks
 david jencks



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread David Jencks
Also, the jca mbean I wrote uses Doug Lea's implementation for the actual
pool.

david

On 2003.03.29 11:59 Scott M Stark wrote:
 The thread pool needs to be a true mbean service with stats and its
 configuration
 exposed via JMX, not just a class. The JCA api and associated component
 David
 mentioned should be a good start for such a service.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 - Original Message - 
 From: Bela Ban [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, March 29, 2003 7:59 AM
 Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss?
 
 
  Thomas Peuss wrote:
  
   Hello!
  
   I need a thread pool to simplify my code for the HTTP-loadbalancer.
   Is there a generic ThreadPool in JBoss-code (HEAD)? 
  
  
  I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called 
  PooledExecutor). It will be part of JDK 1.5 (Tiger).
  
  
  -- 
  Bela Ban
  www.javagroups.com
  (408) 316-4459
 
 
 
 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread Bill Burke
I say write your own pool.  You can usually optimize it more closely than a
generic service.  Well, that's my experience from writing the PooledInvoker.

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of David
 Jencks
 Sent: Saturday, March 29, 2003 12:44 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss?


 Also, the jca mbean I wrote uses Doug Lea's implementation for the actual
 pool.

 david

 On 2003.03.29 11:59 Scott M Stark wrote:
  The thread pool needs to be a true mbean service with stats and its
  configuration
  exposed via JMX, not just a class. The JCA api and associated component
  David
  mentioned should be a good start for such a service.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Bela Ban [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Saturday, March 29, 2003 7:59 AM
  Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss?
 
 
   Thomas Peuss wrote:
  
Hello!
   
I need a thread pool to simplify my code for the HTTP-loadbalancer.
Is there a generic ThreadPool in JBoss-code (HEAD)?
  
  
   I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called
   PooledExecutor). It will be part of JDK 1.5 (Tiger).
  
  
   --
   Bela Ban
   www.javagroups.com
   (408) 316-4459
 
 
 
  ---
  This SF.net email is sponsored by:
  The Definitive IT and Networking Event. Be There!
  NetWorld+Interop Las Vegas 2003 -- Register today!
  http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of David
 Jencks
 Sent: Saturday, March 29, 2003 10:55 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] hsqldb options


 Prompted by a customer, I did some experiments with hsqldb options.

 Currently we specify a tcp port and require a hsqldb mbean to start the
 hsqldb server.  This opens a port and requires explicit hsqldb shutdown.

 Two other options that appear to work are:

 specify url jdbc:hsqldb:. and remove the hsqldb mbean.  This results in a
 totally in memory db, nothing saved to disk.  IMO this is appropriate for
 most of the testsuite since it eliminates problems with data not being
 cleaned  up between test runs.

 specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.
 This results
 in the db saved in a couple of files named like somefile.  No port is
 opened.  No explicit shutdown of hsqldb  seems to be required (although I
 didn't test how much data is actually saved)

 Could someone who knows more about hsqldb  please explain clearly why we
 would want to continue using the setup we  have now rather than one of the
 tcp-port free options?



Man, if only hsqldb was transactional.  We should recruit them to become a
JBoss project and put keen transactional minds like David Jencks on the
subject.  A fully transactional in-memory DBMS would kick the crap out of
everybody in benchmarking.  I'm surprise Oracle 9iAS doesn't run in-process
with the Oracle DBMS already

Bill



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Sacha Labourey
Well, for quick prototyping it is nice to use the persistent version which
allows to use JBossMQ for example and restart JBoss without loosing
persistent messages.

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Scott M Stark
 Sent: samedi, 29. mars 2003 18:45
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] hsqldb options
 
 
 There is no reason why we can't just document both configs 
 and let the user
 choose what they want. The pure in memory version seems like 
 the better
 default configuration.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 - Original Message - 
 From: David Jencks [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, March 29, 2003 7:55 AM
 Subject: [JBoss-dev] hsqldb options
 
 
  Prompted by a customer, I did some experiments with hsqldb options.
  
  Currently we specify a tcp port and require a hsqldb mbean 
 to start the
  hsqldb server.  This opens a port and requires explicit 
 hsqldb shutdown.
  
  Two other options that appear to work are:
  
  specify url jdbc:hsqldb:. and remove the hsqldb mbean.  
 This results in a
  totally in memory db, nothing saved to disk.  IMO this is 
 appropriate for
  most of the testsuite since it eliminates problems with 
 data not being
  cleaned  up between test runs.
  
  specify url jdbc:hsqldb:somefile and remove the hsqldb 
 mbean.  This results
  in the db saved in a couple of files named like somefile.  
 No port is
  opened.  No explicit shutdown of hsqldb  seems to be 
 required (although I
  didn't test how much data is actually saved)
  
  Could someone who knows more about hsqldb  please explain 
 clearly why we
  would want to continue using the setup we  have now rather 
 than one of the
  tcp-port free options?
  
  Thanks
  david jencks
 
 
 
 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Sacha Labourey
Did you take a look at McKoi? http://www.mckoi.com/database/

From the DOC:
=
There are four transaction isolation levels defined by the SQL standard.
Each isolation level provides varying degrees of protection from seeing
changes made by concurrent connections. The Mckoi database engine supports
the strongest isolation level defined by the standard -
TRANSACTION_SERIALIZABLE. This isolation level prevents a transaction from
seeing all types of concurrent changes. The Mckoi database engine achieves
this through a multi-version data model that efficiently manages and
isolates multiple views of the underlying data. 

During a transaction the connection sees a version (or snapshot) of the
database that is isolated from any changes made by other connections.
Additionally, any changes made within the context of a transaction are
isolated from the rest of the database. This means that while a transaction
is open the view a connection has of the database is blind from changes made
by other concurrent connections. 

The multi-version data model allows the Mckoi database engine to avoid all
inter-transactional table/row locking and deadlock issues. No tables or rows
are locked between concurrent transactions. While one transaction is reading
from a table, another transaction may update the table at the same time. Any
data consistency conflicts (for example, two connections committing a change
that deletes the same row from a table) are detected when a transaction is
committed. 



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Bill Burke
 Sent: samedi, 29. mars 2003 19:00
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] hsqldb options
 
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] 
 Behalf Of David
  Jencks
  Sent: Saturday, March 29, 2003 10:55 AM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] hsqldb options
 
 
  Prompted by a customer, I did some experiments with hsqldb options.
 
  Currently we specify a tcp port and require a hsqldb mbean 
 to start the
  hsqldb server.  This opens a port and requires explicit 
 hsqldb shutdown.
 
  Two other options that appear to work are:
 
  specify url jdbc:hsqldb:. and remove the hsqldb mbean.  
 This results in a
  totally in memory db, nothing saved to disk.  IMO this is 
 appropriate for
  most of the testsuite since it eliminates problems with 
 data not being
  cleaned  up between test runs.
 
  specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.
  This results
  in the db saved in a couple of files named like somefile.  
 No port is
  opened.  No explicit shutdown of hsqldb  seems to be 
 required (although I
  didn't test how much data is actually saved)
 
  Could someone who knows more about hsqldb  please explain 
 clearly why we
  would want to continue using the setup we  have now rather 
 than one of the
  tcp-port free options?
 
 
 
 Man, if only hsqldb was transactional.  We should recruit 
 them to become a
 JBoss project and put keen transactional minds like David 
 Jencks on the
 subject.  A fully transactional in-memory DBMS would kick the 
 crap out of
 everybody in benchmarking.  I'm surprise Oracle 9iAS doesn't 
 run in-process
 with the Oracle DBMS already
 
 Bill
 
 
 
 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Scott M Stark
Thinking more about this, the default config should continue to be the file
based persistence version since that is what users may already be using
for a persistent store across server restarts. If you want a change in this
behavior you need to change the hsqldb jca setup. Just document it in the
configs so its easy to do.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Scott M Stark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 9:44 AM
Subject: Re: [JBoss-dev] hsqldb options


 There is no reason why we can't just document both configs and let the user
 choose what they want. The pure in memory version seems like the better
 default configuration.
 



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Generic ThreadPool in JBoss?

2003-03-29 Thread Scott M Stark
And that is contrary to the generic services architecture we want. First
demonstrate the generic service does not work before coding a one-off.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 9:52 AM
Subject: RE: [JBoss-dev] Generic ThreadPool in JBoss?


 I say write your own pool.  You can usually optimize it more closely than a
 generic service.  Well, that's my experience from writing the PooledInvoker.
 
 Bill



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] XMBean and transient attributes

2003-03-29 Thread Scott M Stark
I'm working on updating the xmbean tests in 3.2 to make sure what we will
have in the 3.2.0 release is usable and there is an issue with transient attributes
and the default value for currencyTimeLimit. An attribute element like:

   attribute access=read-write default=jboss.security:service=JaasSecurityManager
  descriptionSecMgr is a read-write attribute added at the metadata level
 for which there is no state in the User2 instance.
  /description
  nameSecMgr/name
  typejavax.management.ObjectName/type
   /attribute

where there is no currencyTimeLimit defined fails to have a value for this attribute,
and a value cannot be set. Given that it has a default value this does not seem like
valid behavior. If the currencyTimeLimit set to -1 then the default value is seen
as the initial value for the attribute and it may be updated.

   attribute access=read-write default=jboss.security:service=JaasSecurityManager
  descriptionSecMgr is a read-write attribute added at the metadata level
 for which there is no state in the User2 instance.
  /description
  nameSecMgr/name
  typejavax.management.ObjectName/type
  descriptors
 currencyTimeLimit value=-1/ 
  /descriptors
   /attribute

The question is why should a failure to specify the attribute descriptors result in
an unusable attribute? Either the caching logic is faulty or the implicit settings for
the attribute descriptors a not correct.




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Bill Burke
Too many writes, to many Optimistic exceptions.  TRANSACTION_SERIALIZABLE
usually is considered a performance bottleneck in the same way that our
QueuedPessismistic Entity bean lock can be a bottleneck as well.  I would
like to try out ECPERF with Mckoi to see what kind of performance boost we
could get.

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Sacha
 Labourey
 Sent: Saturday, March 29, 2003 1:09 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] hsqldb options


 Did you take a look at McKoi? http://www.mckoi.com/database/

 From the DOC:
 =
 There are four transaction isolation levels defined by the SQL standard.
 Each isolation level provides varying degrees of protection from seeing
 changes made by concurrent connections. The Mckoi database engine supports
 the strongest isolation level defined by the standard -
 TRANSACTION_SERIALIZABLE. This isolation level prevents a transaction from
 seeing all types of concurrent changes. The Mckoi database engine achieves
 this through a multi-version data model that efficiently manages and
 isolates multiple views of the underlying data.

 During a transaction the connection sees a version (or snapshot) of the
 database that is isolated from any changes made by other connections.
 Additionally, any changes made within the context of a transaction are
 isolated from the rest of the database. This means that while a
 transaction
 is open the view a connection has of the database is blind from
 changes made
 by other concurrent connections.

 The multi-version data model allows the Mckoi database engine to avoid all
 inter-transactional table/row locking and deadlock issues. No
 tables or rows
 are locked between concurrent transactions. While one transaction
 is reading
 from a table, another transaction may update the table at the
 same time. Any
 data consistency conflicts (for example, two connections
 committing a change
 that deletes the same row from a table) are detected when a transaction is
 committed.



  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On
  Behalf Of Bill Burke
  Sent: samedi, 29. mars 2003 19:00
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] hsqldb options
 
 
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]
  Behalf Of David
   Jencks
   Sent: Saturday, March 29, 2003 10:55 AM
   To: [EMAIL PROTECTED]
   Subject: [JBoss-dev] hsqldb options
  
  
   Prompted by a customer, I did some experiments with hsqldb options.
  
   Currently we specify a tcp port and require a hsqldb mbean
  to start the
   hsqldb server.  This opens a port and requires explicit
  hsqldb shutdown.
  
   Two other options that appear to work are:
  
   specify url jdbc:hsqldb:. and remove the hsqldb mbean.
  This results in a
   totally in memory db, nothing saved to disk.  IMO this is
  appropriate for
   most of the testsuite since it eliminates problems with
  data not being
   cleaned  up between test runs.
  
   specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.
   This results
   in the db saved in a couple of files named like somefile.
  No port is
   opened.  No explicit shutdown of hsqldb  seems to be
  required (although I
   didn't test how much data is actually saved)
  
   Could someone who knows more about hsqldb  please explain
  clearly why we
   would want to continue using the setup we  have now rather
  than one of the
   tcp-port free options?
  
 
 
  Man, if only hsqldb was transactional.  We should recruit
  them to become a
  JBoss project and put keen transactional minds like David
  Jencks on the
  subject.  A fully transactional in-memory DBMS would kick the
  crap out of
  everybody in benchmarking.  I'm surprise Oracle 9iAS doesn't
  run in-process
  with the Oracle DBMS already
 
  Bill
 
 
 
  ---
  This SF.net email is sponsored by:
  The Definitive IT and Networking Event. Be There!
  NetWorld+Interop Las Vegas 2003 -- Register today!
  http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 



 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!

RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Bill Burke
Strange, seems that you can turn of commit conflicts for dirty reads.  This
is actually READ_COMMITTED behavior.  Cool.  This DB seem cool.  Wonder how
well it works.


 -Original Message-
 From: Bill Burke [mailto:[EMAIL PROTECTED]
 Sent: Saturday, March 29, 2003 3:00 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] hsqldb options


 Too many writes, to many Optimistic exceptions.
 TRANSACTION_SERIALIZABLE usually is considered a performance
 bottleneck in the same way that our QueuedPessismistic Entity
 bean lock can be a bottleneck as well.  I would like to try out
 ECPERF with Mckoi to see what kind of performance boost we could get.

 Bill

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Behalf Of Sacha
  Labourey
  Sent: Saturday, March 29, 2003 1:09 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] hsqldb options
 
 
  Did you take a look at McKoi? http://www.mckoi.com/database/
 
  From the DOC:
  =
  There are four transaction isolation levels defined by the SQL standard.
  Each isolation level provides varying degrees of protection from seeing
  changes made by concurrent connections. The Mckoi database
 engine supports
  the strongest isolation level defined by the standard -
  TRANSACTION_SERIALIZABLE. This isolation level prevents a
 transaction from
  seeing all types of concurrent changes. The Mckoi database
 engine achieves
  this through a multi-version data model that efficiently manages and
  isolates multiple views of the underlying data.
 
  During a transaction the connection sees a version (or snapshot) of the
  database that is isolated from any changes made by other connections.
  Additionally, any changes made within the context of a transaction are
  isolated from the rest of the database. This means that while a
  transaction
  is open the view a connection has of the database is blind from
  changes made
  by other concurrent connections.
 
  The multi-version data model allows the Mckoi database engine
 to avoid all
  inter-transactional table/row locking and deadlock issues. No
  tables or rows
  are locked between concurrent transactions. While one transaction
  is reading
  from a table, another transaction may update the table at the
  same time. Any
  data consistency conflicts (for example, two connections
  committing a change
  that deletes the same row from a table) are detected when a
 transaction is
  committed.
 
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On
   Behalf Of Bill Burke
   Sent: samedi, 29. mars 2003 19:00
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] hsqldb options
  
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
   Behalf Of David
Jencks
Sent: Saturday, March 29, 2003 10:55 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] hsqldb options
   
   
Prompted by a customer, I did some experiments with hsqldb options.
   
Currently we specify a tcp port and require a hsqldb mbean
   to start the
hsqldb server.  This opens a port and requires explicit
   hsqldb shutdown.
   
Two other options that appear to work are:
   
specify url jdbc:hsqldb:. and remove the hsqldb mbean.
   This results in a
totally in memory db, nothing saved to disk.  IMO this is
   appropriate for
most of the testsuite since it eliminates problems with
   data not being
cleaned  up between test runs.
   
specify url jdbc:hsqldb:somefile and remove the hsqldb mbean.
This results
in the db saved in a couple of files named like somefile.
   No port is
opened.  No explicit shutdown of hsqldb  seems to be
   required (although I
didn't test how much data is actually saved)
   
Could someone who knows more about hsqldb  please explain
   clearly why we
would want to continue using the setup we  have now rather
   than one of the
tcp-port free options?
   
  
  
   Man, if only hsqldb was transactional.  We should recruit
   them to become a
   JBoss project and put keen transactional minds like David
   Jencks on the
   subject.  A fully transactional in-memory DBMS would kick the
   crap out of
   everybody in benchmarking.  I'm surprise Oracle 9iAS doesn't
   run in-process
   with the Oracle DBMS already
  
   Bill
  
  
  
   ---
   This SF.net email is sponsored by:
   The Definitive IT and Networking Event. Be There!
   NetWorld+Interop Las Vegas 2003 -- Register today!
   http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
   https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 
  ---
  This SF.net email is sponsored by:
  The Definitive IT and Networking Event. Be There!
  NetWorld+Interop Las Vegas 2003 -- 

[JBoss-dev] [ jboss-Bugs-710396 ] Deployed .war unaccessible in Tomcat 4.1

2003-03-29 Thread SourceForge.net
Bugs item #710396, was opened at 2003-03-26 15:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=710396group_id=22866

Category: CatalinaBundle
Group: v3.2
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Stefan Reich (sreich)
Assigned to: Scott M Stark (starksm)
Summary: Deployed .war unaccessible in Tomcat 4.1

Initial Comment:
Platform MacOSX 10.2.4, JDK 1.4.1, Jboss 3.2 latest CVS, Tomcat 4.1.24 (and 4.1.18).

Some recent change broke tomcat deployment. Although there is no error during the 
deployment, the servlet can't be accessed. To reproduce try to access jmx-console.


--

Comment By: Remy Maucherat (remm)
Date: 2003-03-29 12:46

Message:
Logged In: YES 
user_id=24140

Let's start with the first issue (the NPE).
Since you can build the bundle, could you try using the new
SAR based packaging ? If there's a path related problem, it
could help (or makes things worse, but in any case, it needs
testing).
Use the bundle-express target to create the SAR based bundle.

--

Comment By: Stefan Reich (sreich)
Date: 2003-03-28 15:26

Message:
Logged In: YES 
user_id=429729

Great, the attachment is too long for SF. You can also check out and build ecperf from 
the jboss cvs, which will give you the same files.

--

Comment By: Stefan Reich (sreich)
Date: 2003-03-28 15:16

Message:
Logged In: YES 
user_id=429729

When I launch run.sh from the local directory I am able to access jmx-console. That's 
fine.
However, when I deploy emulator.ear and ecperf.ear from ECperf the servlet can't find 
the java:comp context. This used to work about two weeks ago.
I attached the jar files. 
To reproduce: untar the attachment in your deployment dir and start the container.
Don't worry if you see SQLException exceptions during deployment, the exception below 
happens regardless if the database is up or not:

javax.servlet.ServletException: comp not bound
at 
com.sun.ecperf.supplier.web.SupplierDomainServlet.init(SupplierDomainServlet.java:94)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
[..]
14:26:20,012 ERROR [STDERR] javax.naming.NameNotFoundException: comp not bound
14:26:20,014 ERROR [STDERR] at 
org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
14:26:20,014 ERROR [STDERR] at 
org.jnp.server.NamingServer.getBinding(NamingServer.java:503)
14:26:20,014 ERROR [STDERR] at 
org.jnp.server.NamingServer.getObject(NamingServer.java:509)
14:26:20,015 ERROR [STDERR] at 
org.jnp.server.NamingServer.lookup(NamingServer.java:253)
14:26:20,015 ERROR [STDERR] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:492)
14:26:20,015 ERROR [STDERR] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:471)
14:26:20,016 ERROR [STDERR] at 
javax.naming.InitialContext.lookup(InitialContext.java:347)
14:26:20,016 ERROR [STDERR] at 
com.sun.ecperf.supplier.web.SupplierDomainServlet.init(SupplierDomainServlet.java:86)
14:26:20,016 ERROR [STDERR] at 
javax.servlet.GenericServlet.init(GenericServlet.java:256)
14:26:20,017 ERROR [STDERR] at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
14:26:20,017 ERROR [STDERR] at 
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
14:26:20,017 ERROR [STDERR] at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
14:26:20,017 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
14:26:20,018 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
14:26:20,018 ERROR [STDERR] at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
14:26:20,018 ERROR [STDERR] at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
14:26:20,018 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
14:26:20,019 ERROR [STDERR] at 
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
14:26:20,019 ERROR [STDERR] at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
14:26:20,019 ERROR [STDERR] at 

[JBoss-dev] !

2003-03-29 Thread shyu




 
 

 


 


  [] 
[] [] [] [] [] [] [] 
   






* 

* 

* 


95206
(0571) 86465080 86467128 86455732  
(0571)86469732
 13958106746 E_mail[EMAIL PROTECTED] 

www.hzefu.com www.hzefu.net www.hzefu.cn 
 QQ965301




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] What is the diff between the two xmbean default settings

2003-03-29 Thread Scott M Stark
There are two default values in an xmbean attribute declaration, one of
which appears to be ignored. For this attribute:

   attribute access=read-only default=3.14159
  descriptionPi is a read-only attribute added at the metadata level
 for which there is no state in the User2 instance.
  /description
  namePi/name
  typedouble/type
  descriptors
 currencyTimeLimit value=-1/
 default value=3.14159/
  /descriptors
   /attribute

only the default value=3.14159/ in the descriptors results in the attribute
having a value that is accessible via a getAttribute call on the mbean server. What
is the purpose of the default attribute in the attribute element?


Scott Stark
Chief Technology Officer
JBoss Group, LLC



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] XMBean and transient attributes

2003-03-29 Thread Juha-P Lindfors

it should set the value to -1 in the MBeanAttributeInfo descriptor if no
getMethod fields are specified

 // if no method mapping, enable caching automatically
 if (getMethod == null  currTimeLimit ==
null)
descr.setField(CURRENCY_TIME_LIMIT, -1);

-- Juha


On Sat, 29 Mar 2003, Scott M Stark wrote:

 I'm working on updating the xmbean tests in 3.2 to make sure what we will
 have in the 3.2.0 release is usable and there is an issue with transient attributes
 and the default value for currencyTimeLimit. An attribute element like:

attribute access=read-write 
 default=jboss.security:service=JaasSecurityManager
   descriptionSecMgr is a read-write attribute added at the metadata level
  for which there is no state in the User2 instance.
   /description
   nameSecMgr/name
   typejavax.management.ObjectName/type
/attribute

 where there is no currencyTimeLimit defined fails to have a value for this attribute,
 and a value cannot be set. Given that it has a default value this does not seem like
 valid behavior. If the currencyTimeLimit set to -1 then the default value is seen
 as the initial value for the attribute and it may be updated.

attribute access=read-write 
 default=jboss.security:service=JaasSecurityManager
   descriptionSecMgr is a read-write attribute added at the metadata level
  for which there is no state in the User2 instance.
   /description
   nameSecMgr/name
   typejavax.management.ObjectName/type
   descriptors
  currencyTimeLimit value=-1/
   /descriptors
/attribute

 The question is why should a failure to specify the attribute descriptors result in
 an unusable attribute? Either the caching logic is faulty or the implicit settings 
 for
 the attribute descriptors a not correct.




 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Peter Fagerlund
lördagen den 29 mars 2003 kl 18.54 skrev Sacha Labourey:

Well, for quick prototyping it is nice to use the persistent version  
which
allows to use JBossMQ for example and restart JBoss without loosing
persistent messages.
Yes when You want to prototype a remote DB for some reason, the legacy  
start of a org.hsqldb.Server is quick. For running testsuites or using  
a sql-cashe the recommended way is to start the Hypesonic mbean with  
the Persist = false flag, that will yield a non-network hsqldb  
instance. That is about 300% faster then a legacy networked instance.

Read the Change note  [ 636781 ] hsqldb configuration v 1.7.1 here :
http://sourceforge.net/tracker/ 
index.php?func=detailaid=636781group_id=22866atid=381174

Many moons ago Richard punched out a sample mbean for a thirdparty lib  
- that has resulted in the hsqldb legacy mbean with funky lingering  
threads holding on to sockets ...

Other then that the Hypersonic mbean also let us use the Hypersonic  
DatabaseManager in a easy fashion - needed when running as Persist =  
false since that instance is not visible outside of the VM.

The natural way is for the hsqldb team to make a JMX distro - and I  
understand they are working on the DatabaseManager to become a jmx  
component - discussion here :
http://sourceforge.net/forum/forum.php?thread_id=817198forum_id=73673
Also it has been expressed, some directions toward a JMX HSQLDB, for us  
and others to use.

/peter_f



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] What is the diff between the two xmbean default settings

2003-03-29 Thread David Jencks
I think the one that is an attribute of the attribute element is a leftover
from the xmbean implementation in Juha's book, later replaced with the
default element in the descriptors.

david jencks

On 2003.03.29 16:41 Scott M Stark wrote:
 There are two default values in an xmbean attribute declaration, one of
 which appears to be ignored. For this attribute:
 
attribute access=read-only default=3.14159
   descriptionPi is a read-only attribute added at the metadata
 level
  for which there is no state in the User2 instance.
   /description
   namePi/name
   typedouble/type
   descriptors
  currencyTimeLimit value=-1/
  default value=3.14159/
   /descriptors
/attribute
 
 only the default value=3.14159/ in the descriptors results in the
 attribute
 having a value that is accessible via a getAttribute call on the mbean
 server. What
 is the purpose of the default attribute in the attribute element?
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 
 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] What is the diff between the two xmbean default settings

2003-03-29 Thread Scott M Stark
Ok, its not used anywhere in the code so I dropped it from the dtd.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 7:06 PM
Subject: Re: [JBoss-dev] What is the diff between the two xmbean default settings


 I think the one that is an attribute of the attribute element is a leftover
 from the xmbean implementation in Juha's book, later replaced with the
 default element in the descriptors.
 
 david jencks



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development