[JBoss-dev] Running of unit test fails

2003-04-12 Thread Bela Ban
When trying to run my test cases against the cache, I get an file 
permission error. The permissions are okay though.

What does this mean ?
Bela
[sjc370334 bela ]/home/bela/jboss-head/testsuite$ ./build.sh  
-Dtest=cache test
build.sh: *WARNING* Ignoring environment value for $ANT_HOME
build.sh: Executing: /home/bela/jboss-head/tools/bin/ant -logger 
org.apache.tools.ant.NoBannerLogger -Dtest=cache test
Searching for build.xml ...
Buildfile: /home/bela/jboss-head/testsuite/build.xml

_buildmagic:init:
Trying to override old definition of task property
init:
Set timestamp to: 2003-04-12.19-26
test:
executing cache
Created dir: /home/bela/jboss-head/testsuite/output/reports
Created dir: /home/bela/jboss-head/testsuite/output/log
Running org.jboss.test.cache.test.IdentityLockUnitTestCase
Exception in thread main java.security.AccessControlException: access 
denied (java.io.FilePermission 
/home/bela/jboss-head/testsuite/output/reports/TEST-org.jboss.test.cache.test.IdentityLockUnitTestCase.xml 
write)
   at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
   at 
java.security.AccessController.checkPermission(AccessController.java:401)
   at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
   at java.lang.SecurityManager.checkWrite(SecurityManager.java:975)
   at java.io.FileOutputStream.init(FileOutputStream.java:169)
   at java.io.FileOutputStream.init(FileOutputStream.java:131)
   at 
org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:206)
   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.createAndStoreFormatter(JUnitTestRunner.java:550)
   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:495)
TEST org.jboss.test.cache.test.IdentityLockUnitTestCase FAILED

BUILD SUCCESSFUL
Total time: 13 seconds
--
Bela Ban
www.javagroups.com
(408) 316-4459




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Running of unit test fails

2003-04-12 Thread Scott M Stark
It means you are running with a security manager and have not
defined the permissions that are needed.
--

Scott Stark
Chief Technology Officer
JBoss Group, LLC

Bela Ban wrote:
When trying to run my test cases against the cache, I get an file 
permission error. The permissions are okay though.

What does this mean ?
Bela
[sjc370334 bela ]/home/bela/jboss-head/testsuite$ ./build.sh  
-Dtest=cache test
build.sh: *WARNING* Ignoring environment value for $ANT_HOME
build.sh: Executing: /home/bela/jboss-head/tools/bin/ant -logger 
org.apache.tools.ant.NoBannerLogger -Dtest=cache test
Searching for build.xml ...
Buildfile: /home/bela/jboss-head/testsuite/build.xml

_buildmagic:init:
Trying to override old definition of task property
init:
Set timestamp to: 2003-04-12.19-26
test:
executing cache
Created dir: /home/bela/jboss-head/testsuite/output/reports
Created dir: /home/bela/jboss-head/testsuite/output/log
Running org.jboss.test.cache.test.IdentityLockUnitTestCase
Exception in thread main java.security.AccessControlException: access 
denied (java.io.FilePermission 
/home/bela/jboss-head/testsuite/output/reports/TEST-org.jboss.test.cache.test.IdentityLockUnitTestCase.xml 
write)
   at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) 

   at 
java.security.AccessController.checkPermission(AccessController.java:401)
   at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
   at java.lang.SecurityManager.checkWrite(SecurityManager.java:975)
   at java.io.FileOutputStream.init(FileOutputStream.java:169)
   at java.io.FileOutputStream.init(FileOutputStream.java:131)
   at 
org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:206) 

   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.createAndStoreFormatter(JUnitTestRunner.java:550) 

   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:495) 

TEST org.jboss.test.cache.test.IdentityLockUnitTestCase FAILED

BUILD SUCCESSFUL
Total time: 13 seconds




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Daily tests v2

2003-04-12 Thread Sacha Labourey
Hello Fred,

Could you please let me know the advance of this project? I am interested in
it and willing to help setting up the environment.

Cheers,


Sacha

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Fred Hartman
 Sent: vendredi, 11. avril 2003 18:44
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 webMethods has the 3.0.x and 3.2.x branches compiling and running the
 testsuite on 35 OS/JVM combinations. We are preparing to move 
 the results
 host outside our firewall and will allow the JBoss Community to add
 testsuite results for JVM/OS combinations that are not covered to that
 archive. More info will be coming in the next couple weeks.
 
 Cheers,
 Fred
 
 -Original Message-
 From: Chris Kimpton [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 11, 2003 2:16 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Daily tests v2
 
 
 Hi,
 
 I have the my shiny new daily testing going fairly smoothly now, you
 can see the web results here:
 
 http://jboss1.kimptoc.net/
 
 I will point the email nagger to the jboss-dev list any moment now...
 
 It does regular intra-day compiles, linux and winxp (via cygwin) -
 only on jdk1.4 and daily tests (full and unit tests - alternating
 between machines).
 
 Its only using HEAD.  I presume this is used for JBoss4 dev...
 
 So - what else should be covered?  
  - other branches?  
  - other jdks - ie should I try building/testing a minimal system
 under jdk13?
 
 See ya,
 Chris
 
 =
 
 
 __
 Do you Yahoo!?
 Yahoo! Tax Center - File online, calculators, forms, and more
 http://tax.yahoo.com
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex code. Debugging C/C++ programs can leave you 
 feeling lost and 
 disoriented. TotalView can help you find your way. Available 
 on major UNIX 
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex code. Debugging C/C++ programs can leave you 
 feeling lost and 
 disoriented. TotalView can help you find your way. Available 
 on major UNIX 
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Daily tests v2

2003-04-12 Thread Fred Hartman
The idea is a simple build.xml with minimal setup (cvs client, Ant, a JDK, a
couple modifications to an Ant properties file).

The build.xml does the cvs copyout, compile, test case run, shutdown and
then FTPs the results to a web site. This build.xml only works unattended
with fixes that are in =3.0.7 and 3.2 branches.

We will be scheduling the tester to run regularly on the tip of all major
source branches (4.0 will be added soon) and results will be archived for
every release, so anyone can make sure the failures they get from a home
install are the 'correct' set for a given release.

Over time we will be setting up the tester for more JDKs and OSes. The
initial set of OSes is:

  RedHat Linux 2.4.18-26.8.0
  RedHat Linux 2.2.16-22
  RedHat Linux 2.2.14-5.0
  Windows 2000
  Windows NT
  Windows XP
  Solaris 5.9
  AIX 4.3
  AIX 5.1L
  HP-UX 11i
  HP-UX 11

We would also like to extend the test result archive to include results of
testsuite execution using other DBMSes and JMS providers.


-Fred



-Original Message-
From: Sacha Labourey [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2003 5:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Daily tests v2


Hello Fred,

Could you please let me know the advance of this project? I am interested in
it and willing to help setting up the environment.

Cheers,


Sacha

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Fred Hartman
 Sent: vendredi, 11. avril 2003 18:44
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 webMethods has the 3.0.x and 3.2.x branches compiling and running the
 testsuite on 35 OS/JVM combinations. We are preparing to move 
 the results
 host outside our firewall and will allow the JBoss Community to add
 testsuite results for JVM/OS combinations that are not covered to that
 archive. More info will be coming in the next couple weeks.
 
 Cheers,
 Fred
 
 -Original Message-
 From: Chris Kimpton [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 11, 2003 2:16 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Daily tests v2
 
 
 Hi,
 
 I have the my shiny new daily testing going fairly smoothly now, you
 can see the web results here:
 
 http://jboss1.kimptoc.net/
 
 I will point the email nagger to the jboss-dev list any moment now...
 
 It does regular intra-day compiles, linux and winxp (via cygwin) -
 only on jdk1.4 and daily tests (full and unit tests - alternating
 between machines).
 
 Its only using HEAD.  I presume this is used for JBoss4 dev...
 
 So - what else should be covered?  
  - other branches?  
  - other jdks - ie should I try building/testing a minimal system
 under jdk13?
 
 See ya,
 Chris
 
 =
 
 
 __
 Do you Yahoo!?
 Yahoo! Tax Center - File online, calculators, forms, and more
 http://tax.yahoo.com
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex code. Debugging C/C++ programs can leave you 
 feeling lost and 
 disoriented. TotalView can help you find your way. Available 
 on major UNIX 
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex code. Debugging C/C++ programs can leave you 
 feeling lost and 
 disoriented. TotalView can help you find your way. Available 
 on major UNIX 
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] anybody want to integrate JBoss Remoting?

2003-04-12 Thread marc fleury
I am worried that it is in JMX.  It should be an MBEan with SARS. 

marcf

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Bill Burke
 Sent: Wednesday, April 09, 2003 11:00 PM
 To: Jboss-Dev
 Subject: [JBoss-dev] anybody want to integrate JBoss Remoting?
 
 
 I am too busy finalizing the AOP framework and AOP 
 services(Bela has me doing some tasks for him on cache).  
 Does anybody want to integrate JBoss Remoting into EJB?  If 
 anybody is intersted, please coordinate with me.
 
 
 Bill Burke
 Chief Architect
 JBoss Group, LLC
 
 
 Cast your vote for JBoss as JDJ Best App Server
 
http://www.sys-con.com/java/readerschoice2003/vote.cfm



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost
and 
disoriented. TotalView can help you find your way. Available on major
UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Daily tests v2

2003-04-12 Thread Sacha Labourey
OK, We still need to find a way to make this information easy to browse (by
OS/JVM vendor/JVM version/JBoss version etc.)

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Fred Hartman
 Sent: dimanche, 13. avril 2003 00:15
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 The idea is a simple build.xml with minimal setup (cvs 
 client, Ant, a JDK, a
 couple modifications to an Ant properties file).
 
 The build.xml does the cvs copyout, compile, test case run, 
 shutdown and
 then FTPs the results to a web site. This build.xml only 
 works unattended
 with fixes that are in =3.0.7 and 3.2 branches.
 
 We will be scheduling the tester to run regularly on the tip 
 of all major
 source branches (4.0 will be added soon) and results will be 
 archived for
 every release, so anyone can make sure the failures they get 
 from a home
 install are the 'correct' set for a given release.
 
 Over time we will be setting up the tester for more JDKs and OSes. The
 initial set of OSes is:
 
   RedHat Linux 2.4.18-26.8.0
   RedHat Linux 2.2.16-22
   RedHat Linux 2.2.14-5.0
   Windows 2000
   Windows NT
   Windows XP
   Solaris 5.9
   AIX 4.3
   AIX 5.1L
   HP-UX 11i
   HP-UX 11
 
 We would also like to extend the test result archive to 
 include results of
 testsuite execution using other DBMSes and JMS providers.
 
 
 -Fred
 
 
 
 -Original Message-
 From: Sacha Labourey [mailto:[EMAIL PROTECTED]
 Sent: Saturday, April 12, 2003 5:36 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 Hello Fred,
 
 Could you please let me know the advance of this project? I 
 am interested in
 it and willing to help setting up the environment.
 
 Cheers,
 
 
   Sacha
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On 
  Behalf Of Fred Hartman
  Sent: vendredi, 11. avril 2003 18:44
  To: '[EMAIL PROTECTED]'
  Subject: RE: [JBoss-dev] Daily tests v2
  
  
  webMethods has the 3.0.x and 3.2.x branches compiling and 
 running the
  testsuite on 35 OS/JVM combinations. We are preparing to move 
  the results
  host outside our firewall and will allow the JBoss Community to add
  testsuite results for JVM/OS combinations that are not 
 covered to that
  archive. More info will be coming in the next couple weeks.
  
  Cheers,
  Fred
  
  -Original Message-
  From: Chris Kimpton [mailto:[EMAIL PROTECTED]
  Sent: Friday, April 11, 2003 2:16 AM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] Daily tests v2
  
  
  Hi,
  
  I have the my shiny new daily testing going fairly smoothly now, you
  can see the web results here:
  
  http://jboss1.kimptoc.net/
  
  I will point the email nagger to the jboss-dev list any 
 moment now...
  
  It does regular intra-day compiles, linux and winxp (via cygwin) -
  only on jdk1.4 and daily tests (full and unit tests - alternating
  between machines).
  
  Its only using HEAD.  I presume this is used for JBoss4 dev...
  
  So - what else should be covered?  
   - other branches?  
   - other jdks - ie should I try building/testing a minimal system
  under jdk13?
  
  See ya,
  Chris
  
  =
  
  
  __
  Do you Yahoo!?
  Yahoo! Tax Center - File online, calculators, forms, and more
  http://tax.yahoo.com
  
  
  ---
  This SF.net email is sponsored by: Etnus, makers of 
  TotalView, The debugger 
  for complex code. Debugging C/C++ programs can leave you 
  feeling lost and 
  disoriented. TotalView can help you find your way. Available 
  on major UNIX 
  and Linux platforms. Try it free. www.etnus.com
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
  ---
  This SF.net email is sponsored by: Etnus, makers of 
  TotalView, The debugger 
  for complex code. Debugging C/C++ programs can leave you 
  feeling lost and 
  disoriented. TotalView can help you find your way. Available 
  on major UNIX 
  and Linux platforms. Try it free. www.etnus.com
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex code. Debugging C/C++ programs can leave you 
 feeling lost and 
 disoriented. TotalView can help you find your way. Available 
 on major UNIX 
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ---
 

RE: [JBoss-dev] Daily tests v2

2003-04-12 Thread Fred Hartman
Currently the UI is a JSP tree viewer built from the results directory tree,
which is results/JBossVersion/OS/OSVersion/JVMProvider/JVMVersion.


It will be easier to figure out what should be added to the UI once we get
the server public.


-Original Message-
From: Sacha Labourey [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2003 6:25 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Daily tests v2


OK, We still need to find a way to make this information easy to browse (by
OS/JVM vendor/JVM version/JBoss version etc.)

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Fred Hartman
 Sent: dimanche, 13. avril 2003 00:15
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 The idea is a simple build.xml with minimal setup (cvs 
 client, Ant, a JDK, a
 couple modifications to an Ant properties file).
 
 The build.xml does the cvs copyout, compile, test case run, 
 shutdown and
 then FTPs the results to a web site. This build.xml only 
 works unattended
 with fixes that are in =3.0.7 and 3.2 branches.
 
 We will be scheduling the tester to run regularly on the tip 
 of all major
 source branches (4.0 will be added soon) and results will be 
 archived for
 every release, so anyone can make sure the failures they get 
 from a home
 install are the 'correct' set for a given release.
 
 Over time we will be setting up the tester for more JDKs and OSes. The
 initial set of OSes is:
 
   RedHat Linux 2.4.18-26.8.0
   RedHat Linux 2.2.16-22
   RedHat Linux 2.2.14-5.0
   Windows 2000
   Windows NT
   Windows XP
   Solaris 5.9
   AIX 4.3
   AIX 5.1L
   HP-UX 11i
   HP-UX 11
 
 We would also like to extend the test result archive to 
 include results of
 testsuite execution using other DBMSes and JMS providers.
 
 
 -Fred
 
 
 
 -Original Message-
 From: Sacha Labourey [mailto:[EMAIL PROTECTED]
 Sent: Saturday, April 12, 2003 5:36 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Daily tests v2
 
 
 Hello Fred,
 
 Could you please let me know the advance of this project? I 
 am interested in
 it and willing to help setting up the environment.
 
 Cheers,
 
 
   Sacha
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On 
  Behalf Of Fred Hartman
  Sent: vendredi, 11. avril 2003 18:44
  To: '[EMAIL PROTECTED]'
  Subject: RE: [JBoss-dev] Daily tests v2
  
  
  webMethods has the 3.0.x and 3.2.x branches compiling and 
 running the
  testsuite on 35 OS/JVM combinations. We are preparing to move 
  the results
  host outside our firewall and will allow the JBoss Community to add
  testsuite results for JVM/OS combinations that are not 
 covered to that
  archive. More info will be coming in the next couple weeks.
  
  Cheers,
  Fred
  
  -Original Message-
  From: Chris Kimpton [mailto:[EMAIL PROTECTED]
  Sent: Friday, April 11, 2003 2:16 AM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] Daily tests v2
  
  
  Hi,
  
  I have the my shiny new daily testing going fairly smoothly now, you
  can see the web results here:
  
  http://jboss1.kimptoc.net/
  
  I will point the email nagger to the jboss-dev list any 
 moment now...
  
  It does regular intra-day compiles, linux and winxp (via cygwin) -
  only on jdk1.4 and daily tests (full and unit tests - alternating
  between machines).
  
  Its only using HEAD.  I presume this is used for JBoss4 dev...
  
  So - what else should be covered?  
   - other branches?  
   - other jdks - ie should I try building/testing a minimal system
  under jdk13?
  
  See ya,
  Chris
  
  =
  
  
  __
  Do you Yahoo!?
  Yahoo! Tax Center - File online, calculators, forms, and more
  http://tax.yahoo.com
  
  
  ---
  This SF.net email is sponsored by: Etnus, makers of 
  TotalView, The debugger 
  for complex code. Debugging C/C++ programs can leave you 
  feeling lost and 
  disoriented. TotalView can help you find your way. Available 
  on major UNIX 
  and Linux platforms. Try it free. www.etnus.com
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
  ---
  This SF.net email is sponsored by: Etnus, makers of 
  TotalView, The debugger 
  for complex code. Debugging C/C++ programs can leave you 
  feeling lost and 
  disoriented. TotalView can help you find your way. Available 
  on major UNIX 
  and Linux platforms. Try it free. www.etnus.com
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 
 ---
 This SF.net email is sponsored by: Etnus, makers of 
 TotalView, The debugger 
 for complex 

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
 1) POJO pojo = new POJO();
pojo = (POJO)Versioned.makeVersioned(pojo);

That is really pretty tho :)  You need to define the pojo as aspectable
(advisable).

 or
 
 2) Define a constructor-pointcut on the POJO class (I will 
 implement this
 today.)

nice, 

marcf

 Agreed.  A remote proxy must figure out at marshall time how 
 it can comunicate back to the server.

but, but but...

so we are in the AOP remote and we are about to return an object to the
remote caller.  Can the response do 

return AOPRemote.makeRemote(object); ?

So that even the proxy is constructed as needed (meaning when you return?)

marcf

 
 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
 
attachment: winmail.dat

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
 If you use versioning on a POJO that is a the top of
 an object graph, will the children objects also be
 versions when they are modified???
 
 I assume No.  But I think it would make sense for your 

correct.

 Versioning interceptor to wrap up children objets with the 
 versioning proxy also when they are accessed. 
 That way if you do a:

not needed on reference work, just recursively instrument all get/set of the
objects in the graph. As a reference of the top node, if we declare the top
one to be advised, we can in fact dynamically instrument the references for
the same acidity, when they are assigned to the class and that recursively.


 
 pojo = (POJO)Versioned.makeVersioned(pojo);
 pojo.getAccount().getBalance().add(10.00);
 
 The modification of the Balance object will be
 versioned too.  Does that make sense to you??  Do you
 do this now??
 

we can as described in my previous mail. getBalance() is a method that does
a setBalance(getBalance+10.00); and we detect that one change and that one
change only.

marcf

 Regards,
 Hiram
 
 --- Bill Burke [EMAIL PROTECTED] wrote:
  
  
   -Original Message-
   From:
  [EMAIL PROTECTED]
  
 
 [mailto:[EMAIL PROTECTED]
  Behalf Of
   Karthik
   Sent: Thursday, March 27, 2003 1:25 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
  
  
   Hi bill,
  The versioning of POJO is very good. I have
  some issues here. If I
   version a object, then I have to maintain all the
  state in the same POJO
  
  How is this not the general case?  All application
  code accesses the POJO
  through the proxy.  I am going to write a constructor-pointcut that 
  will always return a proxy instead of the real POJO on
  construction.
  
   which is not the general case and will bloat the
  code. The states are
   maintained in the helper classes. Also defining
  each POJO as versioned is
   meaningless. If new proxies are created for each
  transaction with the deep
   copy of all the state or maintain a pool and
  synchronize the state after
   update,  it will become real performance
  bottleneck.How do you tackle this
   problem?
  
  There is only one proxy, but you are correct.  For
  each transaction, a full
  snapshot is taken of the real object.  All access to
  the object is done
  through one proxy.
  
  The performance hit is the full deep copy not the synchronization.
  Synchronization is only:
  
  realObject = snapshot;
  
  Remember, we're optimistically locking here.
  (Although I'd like to
  optionally provide a transactional lock in the near
  future).
  
  The alternative solution is much much more complex.
  The biggest problem
  being, how do you determine when a POJO's state has
  changed?  For instance:
  
  Pojo.someHashMapField.get().setValue(blah).  You see
  my point?
  
  A full deep copy greatly simplifies the code.
  Simplicity == robustness.
  Plus I'm not even sure versioned fields would be
  better performing.  Field
  interception is quite expensive and versioned fields
  would need field
  interception.
  
  The code is under:
  varia/src/main/org/jboss/aop/plugins/Version*.java
  testcase is under
 
 testsuite/src/main/org/jboss/test/aop/bean/Version*.java
  (take a look at the AOP DD under 
  testsuite/src/resource/aop/META-INF/jboss-aop.xml
  too).
  
  Bill
  
  
  
  Correct me if I am missing something.
  
  Where or when can get the code from the CVS?
  
   Thanks
  
   Karthi
  
-Original Message-
From:
  [EMAIL PROTECTED]
   
 
 [mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Thursday, March 27, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
   
   
   
   
 -Original Message-
 From:
  [EMAIL PROTECTED]

 
 [mailto:[EMAIL PROTECTED]
Behalf Of Jeff
 Haynie
 Sent: Wednesday, March 26, 2003 11:51 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration



 JBoss Remoting is much more fabulous.  We
  need to get the
word out on
 it...

 I need to write some darn docs.. Too busy
  trying to get a
new release
 out on our side. Not enough hours in a day.


  I totally agree.  And yes, a constructor
  pointcut is the
way to go.
 The only downside of constructor pointcuts is
  that
reflection bypasses
 the interception!
  Same thing with field interception.  The
  problem is that unlike
 methods, you have to modify the bytecode of
  the calling logic.

 Could you dynamically do an insertBefore into
  the
CtConstructor of the
 advised class which would do the interception,
  even on reflection?

   
I'm not sure...The problem with Versioning and
  Remoting is
that a proxy
object is required.  You have to return a
  different object
than the one
actually constructed.  You getting me?  I'm 

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
Digging throught that thread and the bela discussion of cache.

 There is only one proxy, but you are correct.  For each
 transaction, a full snapshot is taken of the real object.  
 All access to the object is done through one proxy.

The point being made was that there is another way to do this that I find a
little more intuitive (and it seems to solve the Person.getAddress()
instrumentation problem of bela, done). 

Essentially instrument the get/set methods (eventually field in V2 if we can
do it right) and then you are instrumenting the actual instance.   The
reference you are holding to an object, even if dynamically instrumented
(such as an object inserted in cache) is held, get/set do not require that
you get a new reference. 

Sacha pointed out to me in Paris that using a proxy may be a simpler way for
you to deal with the Remoteness aspect, which does always require this
proxy, I doesn't' help on the server though. 

 The performance hit is the full deep copy not the
 synchronization. Synchronization is only:
 
 realObject = snapshot;
 
 Remember, we're optimistically locking here.  (Although I'd
 like to optionally provide a transactional lock in the near future).

Ok.  Serialization is needed because you are just doing deep copy of the
object (simple I agree).  But in fact we do have the knowledge of state
changes for most basic types/all application types as we make a requirement.
That means that tracking the individual field changes as in CMP2.0 is a
given.  All individual sets should trigger versioning of the individual
fields.  As we realized in the cache discussion with Bela and you this
essentially does away with the serializable requirement.

 The alternative solution is much much more complex.  The
 biggest problem being, how do you determine when a POJO's 
 state has changed?  For instance:
 
 Pojo.someHashMapField.get().setValue(blah).  You see my point?

For most types it is trivial but for Maps.  Adrian has a very simple
solution to this, pitched it in Paris.  In fact he didn't even men.  Simply
overwrite the class in the class pool so that when a CL asks for HashMap()
you really return a JBossHashMap which has the CRUD operations overloaded
(something like that I wasn't really fully there that night, mostly drunk). 

Simple. 

For most POJOS it is trivial.

Meaning that 

pojo.setSomeField(value); 

is an instrumented method with either

/*
* jboss-tag:acid=true
* 
* when david gets around to writing XDoclet in AOP :)
*
*/
public class stuffWeWantACID

which generates the XML description of it
aspects
class name=ACID.Pojo
interceptor name=doTheAcidVersioning pointcut=get*,set* 
/class

We can then trivially acidify the state of that object as originally
imagined and prototyped by Julien at NIST.  Pure bytecode instrumentation of
the actual reference. 

As far as references in the POJO, we also talked about the fact that we
solve the problem by simply recursing through the ACID reference so that a
tree of state, when reaching leaves is trivially serializable and thus
achieving fined grained acidity of the tree state. 

 better performing.  Field interception is quite expensive and
 versioned fields would need field interception.

get/set requirement would trivially solve the problem in first iteration,
field in second.  As we know it is the same class of problem we see in ACID,
Cache and persistence. Simply that we need to instrument get/set on the
code.


marcf

attachment: winmail.dat