Re: [JBoss-dev] Nukes/JBoss?
Look in the forums http://www.jboss.org/jive.jsp Charles Goodwin said: 1) I'm looking for the Nukes development mailing list, is this the right place? 2) If it is the right place, have you considered having a separate mailing list for Nukes given the high traffic nature of this list and the fact that Nukes is distinctly different from JBoss as an application? 3) Can you post a link to your lists on jboss.org? It took me ages to find this list and I only found it through Google. - Charlie The future of webapps - www.xwt.org --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Proxy generator broken
On Fri, 2002-09-20 at 16:38, Dain Sundstrom wrote: Thanks Scott. I think the proxy code needs a good rewrite. It seems to use a lot complicated code and array tricks because the writer decided not to use the collections APIs. If we can simplify this code, I think we should change our usage of java.util.Proxy over to our generator, as ours is easier in debugging because it names classes my.ParentClass$Proxy instead of $Proxy. The problem was (is?) that BCEL uses arrays rather than collections in it's API to generate the byte code so you end up doing lots of Collection - array - Collection manipulation. At the time there was no easy way to map java.lang.ref.Method et al to the BCEL representations, so there's a bit of crap to get around that stuff too. Also BCELifier (which takes a .class file and produces a BCEL implementation of a class that produces the same .class) wasn't available either However...BCEL has matured quite a lot since the first port I did back in Feb. so the code definitely needs a review against improvements in the BCEL APIs. I'll have a look today (dunno if my R/W is still active tho') Neale -dain Hiram Chirino wrote: I'll look into it right away. Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-cvs] jboss-transaction/src/main/org/jb oss/tm TransactionImpl.java
The problem with all these 'tricks' to avoid synchronization is that they
rely on all sorts of assumptions about both the compiler and the underlying
memory model. Unfortunately the JVM spec is such that you really can't make
these assumptions.
See
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
and in particular Doug Lea's thoughts on syncronization and the Memory model..
http://gee.cs.oswego.edu/dl/cpj/jmm.html
On Wed, Jul 17, 2002 at 05:21:07PM +0100, Kevin Conner wrote:
Ole Husgaard wrote:
+ // Using the construct
+ // try {
+ // txCapsule.doSomething();
+ // } catch (NullPointerException ex) {
+ // throw new IllegalStateException(No transaction.);
+ // }
+ // may look like bad programming style, but it is
needed to avoid to
+ // synchronize on these methods. If we used a construct like
+ // if (txCapsule == null)
+ // throw new IllegalStateException(No transaction.);
+ // txCapsule.doSomething();
+ // we can get spurious NullPointerExceptions when
racing with the
+ // transaction completion.
+
public void commit()
throws RollbackException,
@@ -68,9 +83,11 @@
java.lang.IllegalStateException,
SystemException
{
- if( txCapsule == null )
+ try {
+ txCapsule.commit();
+ } catch (NullPointerException ex) {
throw new IllegalStateException(No transaction.);
- txCapsule.commit();
+ }
Interesting... Is this actually faster then synchronizing? Have you
measured it?
How about:
public void commit()
{
final TxCapsule localTxCapsule = txCapsule ;
if (localTxCapsule == null)
throw new IllegalStateException(No transaction.) ;
localTxCapsule.commit() ;
}
Kev
Kevin Conner
Orchard Information Systems Limited
Newcastle Technopole, Kings Manor
Newcastle Upon Tyne, NE1 6PA. United Kingdom
Registered in England, Number 1900078
Tel: +44 (0) 191-2032536 Fax: +44 (0) 191 2302515
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
regards
Neale Swinnerton
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-cvs] jboss-transaction/src/main/org/jb oss/tm TransactionImpl.java
But this isn't related to the problem. This code is trying to protect against a stale volatile reference occuring between the initial comparison and the access, it is not saying that the object being referenced is thread safe. It is still the responsibility of the txCapsule object to protect itself using synchronization. The code is structured this way (catching NPE's) to avoid synchronization as stated in the comment in the code. If all the methods in TransactionImpl were synchronized there would be no problem, apart from the performance. Whether txCapsule is synchronized is irrelevant. However, it works. It's not based on any assumptions about the compiler or the JVM. Replacing ugly fully functional code with a 'neat trick' based on the assumption that the compiler won't optimize it is IMHO a waste of everyones effort. Are there any compiler optimisations which would invalidate this code? The assumption is that the volatile reference will be copied into a local Exactly my point... :-) -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-cvs] jboss-transaction/src/main/org/jb oss/tm TransactionImpl.java
On Thu, Jul 18, 2002 at 12:24:50PM +0100, Kevin Conner wrote:
The code is structured this way (catching NPE's) to avoid
synchronization as
stated in the comment in the code. If all the methods in
TransactionImpl were
synchronized there would be no problem, apart from the
performance. Whether
txCapsule is synchronized is irrelevant.
No, the code is structured this way to avoid the race between
checking the volatile reference and accessing it. Whether
txCapsule is synchronised is very relevant because the assumption
in the code is that txCapsule is thread safe. It is the
responsibility of txCapsule to make sure that all data accessed
within is correct.
OK, the fact that TxCapsule is thread-safe *is* important in the overall
scheme of things, but for the purpose of this argument, 'Is there a better
way than catching the NPE's it's not'
If every method commit(), rollback(), delistResource() etc. were
of the form
synchronized doSomething() {
if (txCapsule == null)
throw new IllegalStateException(No transaction.);
txCapsule.doSomething();
}
Then there would be no problem 'cos the setDone() method is also synchronized.
txCapsule cannot change between the check and the access. By using Ole's
pattern of catching the NPE, you effectively make the check and access an
atomic action - no race possible.
I think we're really talking the same thing. Ole's pattern works, is ugly,
other solutions are tricks and 'may' have issues.
If you want to carry on flogging this horse, carry onI'm happy as is.
--
regards
Neale Swinnerton
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-cvs] jboss-transaction/src/main/org/jb oss/tm TransactionImpl.java
Yep, but you cannot guarantee the source of the NPE. It is feasible that the NPE could be generated by a problem in the called methods and this code will hide that. Ah ha! good point, and a reason to change IMHO. It is not a trick, it is the correct use of volatile. The compilers should not optimise the local variable into two access of the volatile. It is syntactically incorrect and less efficient. Do you have any reason to believe this is not the case? If you do then I would genuinely like to hear about it. I don't have any reason to believe either way. My gut feel is that you're right and the compiler shouldn't optimise this. However, I've just been looking at the JVM spec and the JLS and I'm not convinced this is mandatory. It certainly hasn't made my headache any better!!! I see JSR 133 is in progress to nail down the semantics of threads, locks and related features such as volatile variables. From the JSR quote Unfortunately, the current specification has been found to be hard to understand and has subtle, often unintended, implications. /quote At last something I can wholeheartedly agree with. :-) If you want to carry on flogging this horse, carry onI'm happy as is. :-) :-) -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] code submission
Submit a unified patch (diff -u) to the sourceforge jboss project, look for the 'patches' section, note submitting to this will cause sourceforge to send an e-mail to the dev-list anyway. On Wed, Jul 17, 2002 at 06:27:58AM -0400, Seth Sites wrote: I have a patch for bug [ 564890 ] JMS recover/redelivery errors that I have tested and am ready to submit for review. I just have a few questions. 1) What is the best way to submit code patches for bugs. Is diff output preferred or just include the entire method that is changed? 2) Is it best to submit the code through the sourceforge interface at the bug report, or just email it to the dev list? Thanks, Seth --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.org: 500 Internal server error when surfed with lynx
Works for me, no problem. $ lynx --version Lynx Version 2.8.4rel.1 (17 Jul 2001) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6b Built on linux-gnu Mar 15 2002 02:09:19 On Mon, Jul 15, 2002 at 02:39:42PM +0200, Tobias Frech wrote: Hi! If I use lynx to surf www.jboss.org then I get a 500 internal server error displayed along with this output: --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WebSite JSP precompilation.... - need XML Help !
Try !DOCTYPE project [ !ENTITY jsp_mappings SYSTEM jsp_mappings.xml %jsp_mappings; ] and then jsp_mappings; where you need it as before... On Mon, Jul 01, 2002 at 02:59:12PM +0100, Jules Gosnell wrote: I checked out the website module to see if I could fix the build.xml to precompile all the JSP pages. I'm nearly there, but my XML skills are letting me down... I can get Jasper to compile all the JSPs into Java I can compile these into classes. The problem then is that Jasper helpfully generates me an xml snippet containing some servlet/ and servlet-mapping/ directives. This needs to be inserted into the web.xml at the correct place. Jasper is then effectively removed from the equation as all mappings are directed straight to precompiled java servlets, instead of through Jasper. I am trying something like: !DOCTYPE name [!ENTITY jsp_mappings SYSTEM jsp_mappings.xml] at the top of the web.xml amd then : jsp_mappings; where I want the snippet inserted... (jsp_mappings.xml is in WEB-INF with web.xml) No dice : 14:28:44,992 ERROR [XmlFileLoader] Relative URI jsp_mappings.xml; can not be resolved without a document URI.:-1:2 org.xml.sax.SAXParseException: Relative URI jsp_mappings.xml; can not be resolved without a document URI. at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3102) at Does this mean that I need to have some sort of custom resolver registered ? All I want to do is #include a piece of xml into an xml file - is there a better way Thanks all, Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WebSite JSP precompilation.... - need XML Help !
Oh, dunno, I worked out how to do this ages ago, I remember messing around for ages at the time, I just cut and pasted what i'd discovered. since you've got a better solution lets just forget about DTD nastiness. I think xpointer makes this sort of thing easier, but it's not well supported? On Mon, Jul 01, 2002 at 04:14:29PM +0100, Jules Gosnell wrote: No go, Neale, [java] 2002-07-01 04:07:53 - Exception initializing TldLocationsCache: XML parsing error on file /WEB-INF/web.xml: (line 3, col -1): Document root element is missing. I have this at the top of the web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; !DOCTYPE project [!ENTITY jsp_servlets SYSTEM jsp_servlets.xml %jsp_servlets;] Should I only have one DOCTYPE directive ? I'll stick with using ant's replace for the moment - it works fine for this Thanks for the help, Jules Neale Swinnerton wrote: Try !DOCTYPE project [ !ENTITY jsp_mappings SYSTEM jsp_mappings.xml %jsp_mappings; ] and then jsp_mappings; where you need it as before... On Mon, Jul 01, 2002 at 02:59:12PM +0100, Jules Gosnell wrote: I checked out the website module to see if I could fix the build.xml to precompile all the JSP pages. I'm nearly there, but my XML skills are letting me down... I can get Jasper to compile all the JSPs into Java I can compile these into classes. The problem then is that Jasper helpfully generates me an xml snippet containing some servlet/ and servlet-mapping/ directives. This needs to be inserted into the web.xml at the correct place. Jasper is then effectively removed from the equation as all mappings are directed straight to precompiled java servlets, instead of through Jasper. I am trying something like: !DOCTYPE name [!ENTITY jsp_mappings SYSTEM jsp_mappings.xml] at the top of the web.xml amd then : jsp_mappings; where I want the snippet inserted... (jsp_mappings.xml is in WEB-INF with web.xml) No dice : 14:28:44,992 ERROR [XmlFileLoader] Relative URI jsp_mappings.xml; can not be resolved without a document URI.:-1:2 org.xml.sax.SAXParseException: Relative URI jsp_mappings.xml; can not be resolved without a document URI. at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3102) at Does this mean that I need to have some sort of custom resolver registered ? All I want to do is #include a piece of xml into an xml file - is there a better way Thanks all, Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WebSite JSP precompilation.... - sorted !
On Mon, Jul 01, 2002 at 08:08:07AM -0700, marc fleury wrote: |I now have the whole of the first page precompiling properly and, as far |as I can see all the other JSPs aswell, with the exception of the forums |(I don't have the forums jar). | |Who maintains the website and are they interested in helping me to merge |these changes ? I do, I am working on a funky bug at the moment, this sitemesh thing just doesn't work at the moment, Sitemesh has a known issue at the moment, are you getting something like a getOutputStream() already called? I had a poke around in the sitemesh code, but gave up and used the older version of sitemesh from the jboss/website module!!! |The advantage of JSP precompilation is that redeploying the website onto |a loaded server should no longer cause multiple JSP compilations to be |forked - bringing the site to it's knees. yeah that was a problem, the way to do it is to commit the work to jetty (if there is any) and the work to the website and I will rebuild today (I need to do it tonight anyway). marcf --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cvs locked-- what do we do?
I've had this before on a (non-sourceforge) CVS repository, the lock file in the repository needs to deleted, I guess you have to be a sourceforge administrator to do this? Here's a bit about it in the CVS manual... http://www.cvshome.org/docs/manual/cvs_10.html#SEC88 On Mon, Jun 24, 2002 at 11:06:59AM -0400, David Jencks wrote: I'm getting messages like this every 30 sec for about 10 minutes trying to do a checkin. cvs server: [08:04:34] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss-system/src/main/org/jboss/deployment What's the procedure for fixing this? thanks david jencks --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler/beans - New directory
User: neales Date: 02/03/07 08:47:16 jbosstest/src/main/org/jboss/test/proxycompiler/beans - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler/test - New directory
User: neales Date: 02/03/07 08:47:17 jbosstest/src/main/org/jboss/test/proxycompiler/test - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler - New directory
User: neales Date: 02/03/07 08:46:46 jbosstest/src/main/org/jboss/test/proxycompiler - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler/beans/ejb - New directory
User: neales Date: 02/03/07 08:51:42 jbosstest/src/main/org/jboss/test/proxycompiler/beans/ejb - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: neales
Date: 02/03/07 09:03:54
Modified:.build.xml
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.86 +52 -3 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- build.xml 7 Mar 2002 08:56:15 - 1.85
+++ build.xml 7 Mar 2002 17:03:54 - 1.86
@@ -28,7 +28,7 @@
!--tests-jmxri-compliance still needs to run over jmxri.jar --
!--the aim of that test is to check our compliance suite. --
-!-- $Id: build.xml,v 1.85 2002/03/07 08:56:15 pra Exp $ --
+!-- $Id: build.xml,v 1.86 2002/03/07 17:03:54 neales Exp $ --
project default=main name=JBoss/Testsuite
@@ -526,9 +526,39 @@
/target
+ target name=compile-proxycompiler-bean-sources depends=init
+taskdef name=xdoclet classname=xdoclet.ejb.EjbDocletTask/
+
+mkdir dir=${build.gen-src}/
+
+mkdir dir=${build.resources}/proxycompiler/META-INF/
+xdoclet sourcepath=${source.java}
+ destdir=${build.gen-src}
+ classpath=${xdoclet.task.classpath}
+ ejbspec=2.0
+ excludedtags=@version,@author
+ mergedir=${source.resources}/proxycompiler
+ fileset dir=${source.java}
+include name=org/jboss/test/proxycompiler/beans/**/*Bean.java/
+ /fileset
+ packageSubstitution packages=ejb substituteWith=interfaces/
+ remoteinterface/
+ localinterface/
+ homeinterface/
+ localhomeinterface/
+ !--session/--
+ deploymentdescriptor xmlencoding =UTF-8
+ destdir=${build.resources}/proxycompiler/META-INF/
+ jboss xmlencoding=UTF-8
+ version=3.0
+ destdir=${build.resources}/proxycompiler/META-INF
+ mergedir=${source.resources}/proxycompiler/
+/xdoclet
+
+ /target
!-- Compile all class files --
- target name=compile-classes depends=compile-bean-sources,
compile-mbean-sources
+ target name=compile-classes depends=compile-bean-sources,
compile-mbean-sources, compile-proxycompiler-bean-sources
mkdir dir=${build.classes}/
javac destdir=${build.classes}
optimize=${javac.optimize}
@@ -641,7 +671,8 @@
_jars-cmp2,
_jars-jsr77,
_jars-jbossmx,
- _jars-ejbconf
+ _jars-ejbconf,
+ _jars-proxycompiler
/target
!--
@@ -1868,7 +1899,25 @@
include name=META-INF/*.*/
/fileset
/jar
+ /target
+
+ !-- proxy compiler tests --
+ target name=_jars-proxycompiler
+mkdir dir=${build.lib}/
+!-- build ejbconf-test.jar --
+jar jarfile=${build.lib}/proxycompiler-test.jar
+ fileset dir=${build.classes}
+ include name=org/jboss/test/proxycompiler/beans/**/
+ /fileset
+ fileset dir=${build.classes}
+ include name=org/jboss/test/proxycompiler/*/
+ /fileset
+ fileset dir=${build.resources}/proxycompiler/
+ include name=META-INF/*/
+ /fileset
+/jar
+
/target
!-- == --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: neales
Date: 02/03/07 09:03:53
Modified:.build.xml
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.76 +9 -1 jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -r1.75 -r1.76
--- build.xml 6 Mar 2002 01:07:46 - 1.75
+++ build.xml 7 Mar 2002 17:03:53 - 1.76
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.75 2002/03/06 01:07:46 schaefera Exp $ --
+!-- $Id: build.xml,v 1.76 2002/03/07 17:03:53 neales Exp $ --
project default=main name=JBoss/Server
@@ -126,6 +126,13 @@
pathelement path=${apache.log4j.lib}/log4j.jar/
/path
+!-- BCEL --
+property name=apache.bcel.root value=${project.thirdparty}/apache/bcel/
+property name=apache.bcel.lib value=${apache.bcel.root}/lib/
+path id=apache.bcel.classpath
+ pathelement path=${apache.bcel.lib}/bcel.jar/
+/path
+
!-- EDU.oswego.cs.dl.util.concurrent --
property name=oswego.concurrent.root
value=${project.thirdparty}/oswego/concurrent/
property name=oswego.concurrent.lib value=${oswego.concurrent.root}/lib/
@@ -181,6 +188,7 @@
path refid=sun.jsse.classpath/
path refid=sun.jts.classpath/
path refid=apache.log4j.classpath/
+ path refid=apache.bcel.classpath/
path refid=gjt.jpl-util.classpath/
path refid=gnu.getopt.classpath/
path refid=oswego.concurrent.classpath/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler Util.java
User: neales
Date: 02/03/07 09:03:54
Added: src/main/org/jboss/test/proxycompiler Util.java
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/proxycompiler/Util.java
Index: Util.java
===
package org.jboss.test.proxycompiler;
public class Util {
private Util() { }
public final static String getStringRepresentation(int i,
Object ref,
int[] ints,
Object[] objectRefs) {
StringBuffer b = new StringBuffer();
b.append(i = + i + ,);
b.append(ref = + ref + ,);
b.append(ints = {);
for(int j = 0; j ints.length; j++) {
b.append([ + j + ]= + ints[j]);
}
b.append(},);
b.append(objectRefs = {);
for(int j = 0; j objectRefs.length; j++) {
b.append([ + j + ]= + objectRefs[j]);
}
b.append(});
return b.toString();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler/test ProxyCompilerUnitTestCase.java
User: neales
Date: 02/03/07 09:03:55
Added: src/main/org/jboss/test/proxycompiler/test
ProxyCompilerUnitTestCase.java
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/proxycompiler/test/ProxyCompilerUnitTestCase.java
Index: ProxyCompilerUnitTestCase.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*
*/
package org.jboss.test.proxycompiler.test; // Generated package name
import junit.framework.*;
import org.jboss.test.JBossTestCase;
import org.jboss.test.proxycompiler.Util;
import org.jboss.test.proxycompiler.beans.interfaces.ProxyCompilerTest;
import org.jboss.test.proxycompiler.beans.interfaces.ProxyCompilerTestHome;
import java.util.Iterator;
import java.util.Collection;
/**
* ProxyCompilerTestUnitTestCase.java
*
*
* Created: Wed Jan 30 00:16:57 2002
*
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @version
*/
public class ProxyCompilerUnitTestCase extends JBossTestCase
{
private ProxyCompilerTestHome home;
public ProxyCompilerUnitTestCase (String name)
{
super(name);
}
public static Test suite() throws Exception
{
return getDeploySetup(ProxyCompilerUnitTestCase.class,
proxycompiler-test.jar);
}
public void testProxyCompilerTest() throws Exception
{
Integer pk = new Integer(1);
ProxyCompilerTest bean = home.create(pk);
assertEquals(Object argument error, pk, bean.getPk());
bean.setBool(true);
assertTrue(boolean argument error, bean.getBool());
byte byteArg = (byte)123;
bean.setByte(byteArg);
assertEquals(byte argument error, byteArg, bean.getByte());
char charArg = 'N';
bean.setChar(charArg);
assertEquals(char argument error, charArg, bean.getChar());
double doubleArg = 1.5;
bean.setDouble(doubleArg);
assertEquals(double argument error, doubleArg, bean.getDouble(), 0.01);
float floatArg = 1.5f;
bean.setFloat(floatArg);
assertEquals(float argument error, floatArg, bean.getFloat(), 0.01f);
int intArg = 234;
bean.setInt(intArg);
assertEquals(int argument error, intArg, bean.getInt());
long longArg = 23456L;
bean.setLong(longArg);
assertEquals(long argument error, longArg, bean.getLong());
short shortArg = (short)7;
bean.setShort(shortArg);
assertEquals(short argument error, shortArg, bean.getShort());
Object[] objectArrayArg = new Object[]{new Integer(4), Hello Mum, new
Float(123.0)};
bean.setObjectArray(objectArrayArg);
Object[] objectReturnArg = bean.getObjectArray();
for ( int i = 0; i objectArrayArg.length; i++ ) {
assertEquals(Object[] argument error, objectArrayArg[i],
objectReturnArg[i]);
}
int[] intArrayArg = new int[]{2, 4, 6, 8};
bean.setIntArray(intArrayArg);
int[] intReturnArg = bean.getIntArray();
for ( int i = 0; i intArrayArg.length; i++ ) {
assertEquals(int[] argument error, intArrayArg[i], intReturnArg[i]);
}
assertTrue(noArgs argument error, bean.noArgsMethod());
String stringRep = Util.getStringRepresentation(intArg, pk, intArrayArg,
objectArrayArg);
String returnArg = bean.complexSignatureMethod(intArg, pk, intArrayArg,
objectArrayArg);
assertEquals(complex argument error, stringRep, returnArg);
}
protected void setUp()
throws Exception
{
home = (ProxyCompilerTestHome)getInitialContext().lookup(ProxyCompilerTest);
getLog().debug(Remove ProxyCompilerTest bean instances);
Collection beansColl = home.findAll();
for(Iterator beans = beansColl.iterator(); beans.hasNext();) {
ProxyCompilerTest bean = (ProxyCompilerTest)beans.next();
getLog().debug(Removing + bean.getPrimaryKey());
bean.remove();
}
}
}// ProxyCompilerTestUnitTestCase
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: neales
Date: 02/03/07 09:03:52
Modified:jbossbuild.xml
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.100 +8 -1 build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- build.xml 5 Mar 2002 03:16:04 - 1.99
+++ build.xml 7 Mar 2002 17:03:52 - 1.100
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.99 2002/03/05 03:16:04 user57 Exp $ --
+!-- $Id: build.xml,v 1.100 2002/03/07 17:03:52 neales Exp $ --
project default=main name=JBoss/Build
@@ -109,6 +109,10 @@
property name=apache.log4j.root value=${project.thirdparty}/apache/log4j/
property name=apache.log4j.lib value=${apache.log4j.root}/lib/
+!-- BCEL --
+property name=apache.bcel.root value=${project.thirdparty}/apache/bcel/
+property name=apache.bcel.lib value=${apache.bcel.root}/lib/
+
!-- EDU.oswego.cs.dl.util.concurrent --
property name=oswego.concurrent.root
value=${project.thirdparty}/oswego/concurrent/
property name=oswego.concurrent.lib value=${oswego.concurrent.root}/lib/
@@ -614,6 +618,9 @@
/fileset
fileset dir=${gnu.regexp.lib}
include name=*.jar/
+ /fileset
+ fileset dir=${apache.bcel.lib}
+include name=bcel.jar/
/fileset
fileset dir=${sun.jsr77.lib}
include name=jsr77.jar/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/proxycompiler/beans/ejb ProxyCompilerTestBean.java
User: neales
Date: 02/03/07 09:03:54
Added: src/main/org/jboss/test/proxycompiler/beans/ejb
ProxyCompilerTestBean.java
Log:
o Replace org.jboss.proxy.compiler with a BCEL implementation
o Add a test for this.
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/proxycompiler/beans/ejb/ProxyCompilerTestBean.java
Index: ProxyCompilerTestBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*
*/
package org.jboss.test.proxycompiler.beans.ejb; // Generated package name
import java.rmi.RemoteException;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import org.jboss.test.proxycompiler.Util;
/**
* ReadOnlyBean.java
*
*
* Created: Tue Jan 22 17:13:36 2002
*
* @author a href=mailto:[EMAIL PROTECTED];Neale Swinnerton/a
* @version
*
*
* @ejb:bean name=ProxyCompilerTest
* jndi-name=ProxyCompilerTest
* local-jndi-name=LocalProxyCompilerTest
* view-type=both
* type=CMP
* cmp-version=2.x
* primkey-field=pk
* @ejb:pk class=java.lang.Integer
* @ejb:finder signature=java.util.Collection findAll()
*/
public abstract class ProxyCompilerTestBean implements EntityBean
{
public ProxyCompilerTestBean ()
{
}
/**
* @ejb:create-method
*/
public Integer ejbCreate(Integer pk)
{
setPk(pk);
return pk;
}
public void ejbPostCreate(Integer pk)
{
}
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract Integer getPk();
/**
* @ejb:interface-method
*/
public abstract void setPk(Integer pk);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract boolean getBool();
/**
* @ejb:interface-method
*/
public abstract void setBool(boolean arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract byte getByte();
/**
* @ejb:interface-method
*/
public abstract void setByte(byte arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract char getChar();
/**
* @ejb:interface-method
*/
public abstract void setChar(char arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract double getDouble();
/**
* @ejb:interface-method
*/
public abstract void setDouble(double arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract float getFloat();
/**
* @ejb:interface-method
*/
public abstract void setFloat(float arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract int getInt();
/**
* @ejb:interface-method
*/
public abstract void setInt(int arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract long getLong();
/**
* @ejb:interface-method
*/
public abstract void setLong(long arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract short getShort();
/**
* @ejb:interface-method
*/
public abstract void setShort(short arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract Object[] getObjectArray();
/**
* @ejb:interface-method
*/
public abstract void setObjectArray(Object[] arg);
/**
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract int[] getIntArray();
/**
* @ejb:interface-method
*/
public abstract void setIntArray(int[] arg);
/**
* @ejb:interface-method
*/
public boolean noArgsMethod() {
return true;
}
/**
* @ejb:interface-method
*/
public String complexSignatureMethod(int i, Object ref, int[] ints, Object[]
objectRefs) {
return Util.getStringRepresentation(i, ref, ints, objectRefs);
}
public void ejbActivate() throws RemoteException
{
}
public void ejbPassivate() throws RemoteException
{
}
public void ejbLoad() throws RemoteException
{
}
public void ejbStore() throws RemoteException
{
}
public void ejbRemove() throws RemoteException
{
}
public void setEntityContext(EntityContext ctx) throws RemoteException
{
}
public void
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/compiler ProxyImplementationFactory.java Runtime.java Utility.java package.html Proxies.java ProxyCompiler.java
});
- }
- asm.setElement(Object.class);
- }
-}
-// call the InvocationHandler
-String invoke = invoke;
-if (rtype.isPrimitive() rtype != Void.TYPE) {
- String tn = rtype.getName();
- invoke += Character.toUpperCase(tn.charAt(0))
- + tn.substring(1);
-}
-asm.invoke(rClass, invoke, invokeParams);
-if (!rtype.isPrimitive() rtype != Object.class) {
- asm.checkCast(rtype);
-}
-asm.ret();
- }
+ }
+
+ cg.addMethod(factory.createProxyMethod(name,
+i,
+rType,
+pTypes,
+exceptionNames));
}
if (!haveToString) {
- asm.addMember(Modifier.PUBLIC, String.class, toString,
- new Class[] {}, null);
- {
-asm.pushLocal(0);
-asm.invoke(rClass, toString, toStringParams);
-asm.ret();
- }
+ cg.addMethod(factory.createToString());
}
- // Put in the constructor:
- asm.addMember(Modifier.PUBLIC, Void.TYPE, init,
-new Class[] { iClass }, null);
- {
- asm.pushLocal(0);
- asm.invoke(superclass, init, new Class[0]);
- asm.pushLocal(0);
- asm.pushLocal(1);
- asm.setField(asm, InvocationHandler_FIELD);
- asm.ret();
+ /*
+ try {
+ cg.getJavaClass().dump(/tmp/ + proxyClassName + .class);
+ } catch ( java.io.IOException e ) {
+ }
+ */
+
+ return cg.getJavaClass().getBytes();
+ }
+
+ // Protected -
+
+ // Private ---
+ private String[] getNames(Class[] classes) {
+ String[] names = new String[classes.length];
+ for ( int i = 0; i classes.length; i++ ) {
+ names[i] = classes[i].getName();
}
- return asm.getCode();
+ return names;
}
+
+ // Inner classes -
+
}
1.1
jboss/src/main/org/jboss/proxy/compiler/ProxyImplementationFactory.java
Index: ProxyImplementationFactory.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.proxy.compiler;
import org.apache.bcel.Constants;
import org.apache.bcel.classfile.Field;
import org.apache.bcel.classfile.Method;
import org.apache.bcel.generic.ArrayType;
import org.apache.bcel.generic.BasicType;
import org.apache.bcel.generic.ConstantPoolGen;
import org.apache.bcel.generic.ClassGen;
import org.apache.bcel.generic.FieldGen;
import org.apache.bcel.generic.Instruction;
import org.apache.bcel.generic.InstructionFactory;
import org.apache.bcel.generic.InstructionList;
import org.apache.bcel.generic.MethodGen;
import org.apache.bcel.generic.ObjectType;
import org.apache.bcel.generic.PUSH;
import org.apache.bcel.generic.ReferenceType;
import org.apache.bcel.generic.Type;
/**
* Factory to create the bytecode implementation of various methods
* required by the ProxyCompiler
*
* @author a href=mailto:[EMAIL PROTECTED];Neale Swinnerton/a
* @version $Revision: 1.1 $
*/
public class ProxyImplementationFactory {
// Constants -
// Class Names
private final static String RUNTIME_CN= Runtime.class.getName();
private final static String INVOCATION_HANDLER_CN =
InvocationHandler.class.getName();
private final static String STRING_BUFFER_CN =
StringBuffer.class.getName();
//Types
private final static ObjectType RUNTIME_T =
(ObjectType)Utility.getType(Runtime.class);
private final static ObjectType INVOCATION_HANDLER_T =
(ObjectType)Utility.getType(InvocationHandler.class);
private final static ArrayType ARRAY_OF_CLASS_T = new
ArrayType(java.lang.Class, 1);
private final static ObjectType OBJECT_T = new
ObjectType(java.lang.Object);
private final static ArrayType ARRAY_OF_OBJECT_T = new
ArrayType(java.lang.Object, 1);
private final static ObjectType STRING_T = new
ObjectType(java.lang.String);
private final static ObjectType STRING_BUFFER_T = new
ObjectType(java.lang.StringBuffer);
private final static ObjectType PROXY_TARGET_T= new
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/compiler ProxyImplementationFactory.java Runtime.java Utility.java package.html Proxies.java ProxyCompiler.java
Yeah I can have a look at that... On Thu, Mar 07, 2002 at 02:36:31PM -0300, Francisco Reverbel wrote: Hi Neale, On Thu, 7 Mar 2002, Neale Swinnerton wrote: User: neales Date: 02/03/07 09:03:53 Modified:src/main/org/jboss/proxy/compiler Proxies.java ProxyCompiler.java Added: src/main/org/jboss/proxy/compiler ProxyImplementationFactory.java Runtime.java Utility.java package.html Log: o Replace org.jboss.proxy.compiler with a BCEL implementation o Add a test for this. The iiop module also has an on-the-fly compiler, for dynamic stub generation. It is in iiop/src/main/org/jboss/proxy/compiler/IIOPStubCompiler.java Would you be interested in replacing it with a BCEL implementation? Best, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] I WILL BREAK TEST!!!!
FYIif you didn't see the CVS Updates.. I have just checked in the BCEL proxy compiler replacement. I ran the testsuite before I applied my patch and the again after applying the tests and all was OK(i.e. same as Chris's automated message). So I committed, Since this was my first commit I thought I'd better do a clean checkout to make sure I hadn't missed something. With the clean checkout the testsuite doesn't work so good. I was panic-ing a bit about what I'd missed, until this e-mail arrived. Since the CMP 2 tests run OK, and the proxy compiler is fundamental to that. I am pretty confident that my stuff is ok, I guess I've picked up marcs changes, but if you're investigating those, please bear in mind that the proxy compiler not working breaks quite a lot ;-) I'm gonna keep looking at what I done to make sure it's not me. On Thu, Mar 07, 2002 at 12:44:11PM -0800, marc fleury wrote: Ok I am going to commit the work right now, just to make sure I don't end up with the Boston problem where some classes were missing and it was a build broken. I will commit everything I have, IT STILL DOESN'T WORK, specifically the testsuite blows chunks on server side NPE with a getTYPE() problem that sounds like an oversight. I will try to fix before my wife puts my ass in a cab for Paris/London in paris and london I do have DSL so I will try to work from there and will reading email everyday I apologize in advance for the automated bitching from Chris Kimpton (who is coming to the london training, looking forward to talk to you) and I hope this gets resolved soon take care, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guidance required EJB1.1/2.0
On Tue, Mar 05, 2002 at 08:07:26AM -0600, Adrian Brock wrote: Thanks for the patch Neale, works well. Why did you think stateless session beans should support createMETHOD? ;-) Ooops... I was obviously coding in autopilot mode Obviously passing args in is probably pointless for SLSB's, the only use I can think of quickly is to log some message, which is of dubious value in IMHO. However reading the Spec (ejb-2.0-fr2, 7.10.3) createMETHOD is not excluded for SLSB's. Why not leave the feature in, if users want to do stupid thingslet them Last night I completed the work to the verifier and the container so the correct behaviour is observed for EJB1.1 I tried to commit it, but I think the hotel where I'm Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guidance required EJB1.1/2.0
Hmmm, I think everyone agrees it's a stupid thing to do, I guess they forgot to state this explicitly in the spec!! On Tue, Mar 05, 2002 at 11:04:37AM -0600, Adrian Brock wrote: It is excluded for stateless beans, at least I read it that way. :-) If you look at the life-cycle diagram it only mentions create(). I agree the spec is not very definite. When it talks about Session beans in general it includes createMethod, but when it talks about stateless it does not. Certainly in 1.1 you could only have one create(). Regards, Adran On Tue, Mar 05, 2002 at 08:07:26AM -0600, Adrian Brock wrote: Thanks for the patch Neale, works well. Why did you think stateless session beans should support createMETHOD? ;-) Ooops... I was obviously coding in autopilot mode Obviously passing args in is probably pointless for SLSB's, the only use I can think of quickly is to log some message, which is of dubious value in IMHO. However reading the Spec (ejb-2.0-fr2, 7.10.3) createMETHOD is not excluded for SLSB's. Why not leave the feature in, if users want to do stupid thingslet them Last night I completed the work to the verifier and the container so the correct behaviour is observed for EJB1.1 I tried to commit it, but I think the hotel where I'm Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10128 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guidance required EJB1.1/2.0
Hi, I wrote that patch Now Marc gave me r/w access to CVS last week, Unfortunately I am totally bogged down with other (non Jboss) stuff at the moment and haven't had chance to use it to apply my patches, so thanks for jumping in :-) I want to assign some other patches to myself but I don't appear in the drop down list on sourceforge for 'Assign to', I thought that I should appear in the list if I had r/w ? I had a v. brief experiment with a r/w checkout from sourceforge last week and was getting something like 'no write access to the repository message' when trying to do a cvs remove. I was using the :ext: form of CVSROOT, with a pub/private key, I can ssh into [EMAIL PROTECTED] OK using this. Can someone who knows sourceforge confirm that my problem with the 'Assign to' is not the same problem that's causing trouble with cvs remove before I investigate this further? Thanks in advance, Neale Swinnerton On Mon, Mar 04, 2002 at 09:13:03AM -0600, Adrian Brock wrote: Hi, I'm apply the createMETHOD patches from sourceforge. As the patch says the verifier code is incomplete. The 2.0 verifier does not exist, the patch allows createMETHOD for 1.1 I was wondering, do we need to support both 1.1 and 2.0 in the container as well? The spec suggests we should for at least CMP. I couldn't find it stated explicitly for other types. Regards, Adrian _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10128 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guidance required EJB1.1/2.0
OK, Thanks, I'll have a look at this later. On Mon, Mar 04, 2002 at 11:35:27AM -0800, Scott M Stark wrote: Access to the repository is seperate from permissions on the JBoss project web site. That is not the cause of the cvs errors. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Neale Swinnerton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 04, 2002 11:02 AM Subject: Re: [JBoss-dev] Guidance required EJB1.1/2.0 Hi, I wrote that patch Now Marc gave me r/w access to CVS last week, Unfortunately I am totally bogged down with other (non Jboss) stuff at the moment and haven't had chance to use it to apply my patches, so thanks for jumping in :-) I want to assign some other patches to myself but I don't appear in the drop down list on sourceforge for 'Assign to', I thought that I should appear in the list if I had r/w ? I had a v. brief experiment with a r/w checkout from sourceforge last week and was getting something like 'no write access to the repository message' when trying to do a cvs remove. I was using the :ext: form of CVSROOT, with a pub/private key, I can ssh into [EMAIL PROTECTED] OK using this. Can someone who knows sourceforge confirm that my problem with the 'Assign to' is not the same problem that's causing trouble with cvs remove before I investigate this further? Thanks in advance, Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Lets use xdoclet @todo tags
These @todo's are good, I've been using them on my projects for a while.
In particular the ability to browse the html report and see that
package x.y.z or class a.b.c has 50 todo's give's an idea of what sort of
state of completion at implementation is in.
The thing to rememeber is that they only get caught by the ant task if
you put the @todo in the javadoc's at the start of the method/class. A lot of
the usage of FIXME in jboss is in particular snippets of a method.
e.g.
public void doSomething() {
try {
...
} catch (ImportantException e) {
//FIXME: How should we handle this.
}
}
Would need to be...
/**
* @todo How do we handle that ImportantException
*/
public void doSomething() {
try {
...
} catch (ImportantException e) {
// ???
}
}
If @todo are to be used 'you must specify @todo in the javadocs' should
be added to the coding standard.
On Wed, Feb 27, 2002 at 11:22:53AM -0500, David Jencks wrote:
XDoclet has a nice feature that I think we should use. Put @todo tags in
your javadacs and xdoclet will generate a nice html report like the tests
report. This beats FIXME hands down.
Here's and example of usage from xdoclet (which uses this feature on
itself)
/**
* @authorJerome Bernard ([EMAIL PROTECTED])
* @authorAra Abrahamian ([EMAIL PROTECTED])
* @created 31 January 2002
* @version $Revision: 1.4 $
* @todo attributes - XXX: Does this need to be synchronized?
* @todo ifIsGetterMethod, ifIsSetterMethod - TODO: There is a big
overlap
* here with stuff in ejb - have a look.
--
regards
Neale Swinnerton
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] newbie question on log.trace
On Tue, Feb 26, 2002 at 04:16:25AM -0800, marc fleury wrote: |PS: is there a threadTrace() thingy where it creates a new file per thread |that would come it and the messages are linked to a given thread going |through? is that a custom logger? | |You lost me here. What are you trying to track? A thread. A thread is coming in and collecting thread information as it goes. If 2 threads go through the log4j logger and trace do the message get mixed??? in that case it is VERY hard to debug a running system as you don't know what thread is talking. Think of that logger as a PROBE for a given thread going through. It goes through on only the messages originated by that thread get logged in a file. Check out the NDC(Nested Diagnostic Context) in log4j for this quote The NDC class implements nested diagnostic contexts as defined by Neil Harrison in the article Patterns for Logging Diagnostic Messages part of the book Pattern Languages of Program Design 3 edited by Martin et al. A Nested Diagnostic Context, or NDC in short, is an instrument to distinguish interleaved log output from different sources. Log output is typically interleaved when a server handles multiple clients near-simultaneously. Interleaved log output can still be meaningful if each log entry from different contexts had a distinctive stamp. This is where NDCs come into play. Note that NDCs are managed on a per thread basis. NDC operations such as push, pop(), clear(), getDepth() and setMaxDepth(int) affect the NDC of the current thread only. NDCs of other threads remain unaffected. /quote from http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html Ex: you are running a system, something is wrong, if you look at the logs you see 254 threads going through and the messages make no sense. You turn on the logTrace() and ONE thread that is going through gets redirected to a file (or a finite number whatever). Each file is just the talk from ONE thread. Useful for debugging the running system. Yes? marcf | |--jason | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- regards Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Loading array class object by name
On Sun, Feb 24, 2002 at 09:42:21PM -0600, Dain Sundstrom wrote: Thanks Scott. I thought I tried that one... Now do you know an easy way to convert java.lang.object[] or whatever to the signature style [Ljava.lang.Object; (other then string manipulation)? Otherwise, I'll write a conversion function. Hi, There are some utils to do this included with apache's BCEL, I've submitted a patch to replace the org.jboss.proxy.compiler.* (#519626) which uses them a bit. If you do implement a conversion function you should note that Class.getName() is inconsistent in behaviour (and IMHO doesn't behave as documented) wrt primitive types. There is a bug on bug parade (#4369208) which raises the inconsistency javadoc - implementation. The 'problem' is that e.g. Class.getName(Character.TYPE) returns char rather than C -- regards Neale Swinnerton -dain Scott M Stark wrote: The syntax for obtaining array classes using Class.forName is rather wacked, but it does work. For example, to get the class for an Object[], use Class oaClass = Class.forName([Ljava.lang.Object;); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BCEL org.jboss.proxy.compiler
Hi, I've now written this. I'm getting timeouts on sourceforge.net trying to submit the patch, I'll try again in an hour or so... On Wed, Feb 13, 2002 at 01:43:38PM -0600, Dain Sundstrom wrote: Yep this package is an absolute requirement of CMP 2.0. The java.lang.reflect.Proxy package can't generate a subclass of an abstract class, and this is where BCEL could take over. If you want to look into writing a replacement with BCEL that would be very cool (they do have a sample dynamic proxy generator). -dain danch wrote: -- regards Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BCEL org.jboss.proxy.compiler
I've just submitted patch 517088 to completely remove the jboss proxy compiler
and replace it with use of java.lang.reflect.Proxy.
The BCEL looks pretty good for all sorts of stuff, but the JDK Proxy class
does everything that the JBoss one does.
An 'interesting' use of the BCEL would be to post process the .class files
before deployment for production and completely remove the
if (log.isDebugEnabled()) {
...
}
code from the .class file.
I can't get too excited after the miniscule performance increase you'd get
from this (I've followed the log4j discussions on this in the past on this
list and others). but as an intellectual exercise it might be quite
interesting to do...
On Mon, Feb 11, 2002 at 08:35:44PM -0800, Jason Dillon wrote:
Any thoughts on replacing our proxy compiler with the Byte Code
Engineering Library, recently added to the list of Jakarta
sub-projects?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
regards
Neale Swinnerton
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone mind if I rename build.bat to Build.bat?
Why not make the .bat not executable? Since windows machines don't
have the same concept of executable flags in the permissions.
Unfortunately it's a pain to change the permissions of stuff in sourceforge
repositories.
I just run something along the lines of...
$ find . -name build.bat -exec chmod ugo-x {} \;
to stop these little 'annoyances'
On Mon, Dec 10, 2001 at 10:05:56AM -0800, David Budworth wrote:
Does anyone mind if I rename build.bat to Build.bat?
Windows boxes aren't case sensitive, so they'll never see the change,
and for unix types, we can do:
./b[TAB] to get build.sh to expand, as it is now, it stops at
./build. (because .bat and .sh are both executable).
It's a little thing, but it is indeed annyoying.
And you know how us unix types hate typing. :)
Just wanted to check with everyone in case build.bat is REQUIRED to be
lowercase for some reason.
-David
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
regards
Neale Swinnerton
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can we put Jetty 3.1.2 in CVS?
On Thu, Nov 01, 2001 at 12:54:00AM +, Julian Gosnell wrote: I've released the 2.4.3/3.1.3 integration on sourceforge. I was just summoning up the courage to announce it. I guess I'll have to do that now ! I have been intending to get Jetty into JBoss cvs for a while, but I've been very busy getting married for the last month or so. My calendar is now clearing and I promise to do it soon. Greg is/was? hoping that 3.1.3 would be IT and he could then devote all his time to JSDK 2.3. As soon as 3.1.3 begins to look vaguely stable I shall sort this out. Does anyone have any experience in updating a source tree from one cvs repository and the committing it to another ? I figure it would be nice to set up a cron job or something to do this. Or is there a better way to keep two SourceForge cvs repositories in sync ? you should use the cvs import command. The Jetty changes then run in their own branch, in this case any jboss specific changes would run in the main branch. When a new jetty comes along you import the new version again. More details at... http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 Jules Simon Harris wrote: I downloaded jetty 3.1.2 and replaced the jar files in jboss-all on my local machine. It all seems to build and run fine. I needed this version because it fixes some issues I had with calling getLocal() from Struts. The absolute latest version of Struts seems to have undergone an API change which means it longer works with JBoss. Regards, Simon -- regards Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jaws debug mode
From
http://jakarta.apache.org/log4j/docs/manual.html
(Under the Perfomance Heading, point 2)
QUOTE
There has been a serious effort to make this hierarchy walk to be as fast as possible.
END QUOTE
You can apparently speed the walk up further, by choosing the
categories carefully, you should probably consider this even if
you decide to cache the result.
In my local (older) copy of this manual
The typical cost of walking this hierarchy is in the range 5 to 15
microseconds on a Pentium II @ 233 Mhz'
Although this has disappeared from the online version.
regards
Neale Swinnerton
On Wed, Aug 15, 2001 at 01:55:17PM +0200, Vincent Harcq wrote:
Hi,
Does anyone know what the cost of the isXXXEnabled() methods are?
Should we
define booleans after Category creation, that can cache these values to
improve speed, or just keep calling isXXXEnabled() each time?
From the log4j sources:
public
boolean isDebugEnabled() {
if(hierarchy.disable = Priority.DEBUG_INT)
return false;
return Priority.DEBUG.isGreaterOrEqual(this.getChainedPriority());
}
The getChainedPriority is a recursive method:
for(Category c = this; c != null; c=c.parent)
{
if(c.priority != null)
return c.priority;
}
Save the result in a boolean and test the boolean will improve performance.
I am not at all a performance guru, I have no idea at which level it will.
It is a good idea to do what you propose.
--jason
Vincent.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
