RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
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 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 <>
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
> 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
> 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 > <>
RE: [JBoss-dev] Daily tests v2
Currently the UI is a JSP tree viewer built from the results directory tree, which is results/. 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
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 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
RE: [JBoss-dev] anybody want to integrate JBoss Remoting?
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
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] 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] Running of unit test fails
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.(FileOutputStream.java:169) at java.io.FileOutputStream.(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
[JBoss-dev] Running of unit test fails
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.(FileOutputStream.java:169) at java.io.FileOutputStream.(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
