[JBoss-dev] CVS update: jboss build.xml
User: starksm Date: 01/12/29 00:56:05 Modified:.Tag: Branch_2_4 build.xml Log: tomcat3x is jakarta-tomcat-3.2.3 Revision ChangesPath No revision No revision 1.33.2.6 +1 -1 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.33.2.5 retrieving revision 1.33.2.6 diff -u -r1.33.2.5 -r1.33.2.6 --- build.xml 2001/12/29 08:37:51 1.33.2.5 +++ build.xml 2001/12/29 08:56:05 1.33.2.6 @@ -36,7 +36,7 @@ !-- The CVSROOT value -- property name=cvsroot value=:pserver:[EMAIL PROTECTED]:/cvsroot/jboss / !-- The location of the jakarta-tomcat-3.2.3 distribution -- - property name=tomcat3x value=jakarta-tomcat-3.2.4 / + property name=tomcat3x value=jakarta-tomcat-3.2.3 / !-- The location of the jakarta-tomcat-4.0 distribution -- property name=tomcat4x value=jakarta-tomcat-4.0.1 / !-- The location of the Jetty-3.1.3-1 distribution -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/build build.xml
User: starksm
Date: 01/12/29 01:00:46
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Change deltree to delete
Revision ChangesPath
No revision
No revision
1.5.2.3 +2 -2 jnp/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jnp/src/build/Attic/build.xml,v
retrieving revision 1.5.2.2
retrieving revision 1.5.2.3
diff -u -r1.5.2.2 -r1.5.2.3
--- build.xml 2001/11/28 06:16:35 1.5.2.2
+++ build.xml 2001/12/29 09:00:46 1.5.2.3
@@ -199,8 +199,8 @@
!-- Cleans up generated stuff --
!-- === --
target name=clean
-deltree dir=${build.dir}/
-deltree dir=${dist.dir}/
+delete dir=${build.dir}/
+delete dir=${dist.dir}/
/target
!-- === --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/build build.properties
User: starksm Date: 01/12/29 01:23:54 Removed: catalina/src/build Tag: Branch_2_4 build.properties Log: This file should not be in cvs ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HttpSessions: distributed locking
Bill, That is really interesting. Furthermore, for BEA, remember that thanks to their front-end dispatcher, it is always the same server that will receive the invocations (until it fails). Consequently, they don't need distributed locking because until a server dies, there is no distributed state anyway (I mean state that is used on different nodes, state is only replicated but replicas are not used) Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Bill Burke Envoyé : vendredi, 28 décembre 2001 22:14 À : Jboss-Development@Lists. Sourceforge. Net Objet : [JBoss-dev] HttpSessions: distributed locking Weblogic doesn't seem to support concurrent access to clustered HttpSessions. Maybe it is all right for us to be this lazy too. Applications Using Frames Must Coordinate Session Access If you are designing a Web application that utilizes multiple frames, keep in mind that there is no synchronization of requests made by frames in a given frameset. For example, it is possible for multiple frames in a frameset to create multiple sessions on behalf of the client application, even though the client should logically create only a single session. In a clustered environment, poor coordination of frame requests can cause unexpected application behavior. For example, multiple frame requests can reset the application's association with a clustered instance, because the proxy plug-in treats each request independently. It is also possible for an application to corrupt session data by modifying the same session attribute via multiple frames in a frameset. To avoid unexpected application behavior, always use careful planning when accessing session data with frames. You can apply one of the following general rules to avoid common problems: In a given frameset, ensure that only one frame creates and modifies session data. Always create the session in a frame of the first frameset your application uses (for example, create the session in the first HTML page that is visited). After the session has been created, access the session data only in framesets other than the first frameset. ___ 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
[JBoss-dev] CVS update: contrib/jetty/src/build build.xml
User: starksm
Date: 01/12/29 01:33:04
Modified:jetty/src/build Tag: Branch_2_4 build.xml
Log:
Fix bad copy element
Revision ChangesPath
No revision
No revision
1.6.2.4 +2 -2 contrib/jetty/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/src/build/Attic/build.xml,v
retrieving revision 1.6.2.3
retrieving revision 1.6.2.4
diff -u -r1.6.2.3 -r1.6.2.4
--- build.xml 2001/12/11 05:41:55 1.6.2.3
+++ build.xml 2001/12/29 09:33:04 1.6.2.4
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=UTF-8 ?
-!-- $Id: build.xml,v 1.6.2.3 2001/12/11 05:41:55 starksm Exp $ --
+!-- $Id: build.xml,v 1.6.2.4 2001/12/29 09:33:04 starksm Exp $ --
!-- An Ant build file for the jetty-service jar and the
JBoss/Jetty bundle. The buildfile requires a JBoss dist
@@ -121,7 +121,7 @@
copy todir=${bundle.root}/jboss
fileset dir=${jboss.dist} /
/copy
-copy todir=${bundle.root}/jboss/lib/ext file=${jar.file} /
+copy todir=${bundle.root}/jboss/lib/ext file=${jar.file} /
copy todir=${bundle.root}/jboss/conf/jetty
fileset dir=${bundle.root}/jboss/conf/default /
/copy
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: starksm Date: 01/12/29 02:17:09 Modified:src/build Tag: Branch_2_4 build.xml Log: Added unit-tests target Revision ChangesPath No revision No revision 1.34.2.7 +3 -0 jbosstest/src/build/Attic/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/Attic/build.xml,v retrieving revision 1.34.2.6 retrieving revision 1.34.2.7 diff -u -r1.34.2.6 -r1.34.2.7 --- build.xml 2001/12/28 22:42:48 1.34.2.6 +++ build.xml 2001/12/29 10:17:09 1.34.2.7 @@ -241,6 +241,9 @@ ### End testcase build targets === -- + target name=unit-tests +ant antfile=src/build/run_tests.xml target=test-and-report / + /target !-- === -- !-- Creates the binary structure-- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: starksm
Date: 01/12/29 02:22:38
Modified:.Tag: Branch_2_4 build.xml
Log:
Use pathconvert to generate absolute paths to pass to the servlet
builds.
Revision ChangesPath
No revision
No revision
1.33.2.7 +29 -3 jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.33.2.6
retrieving revision 1.33.2.7
diff -u -r1.33.2.6 -r1.33.2.7
--- build.xml 2001/12/29 08:56:05 1.33.2.6
+++ build.xml 2001/12/29 10:22:38 1.33.2.7
@@ -41,6 +41,7 @@
property name=tomcat4x value=jakarta-tomcat-4.0.1 /
!-- The location of the Jetty-3.1.3-1 distribution --
property name=jetty value=Jetty-3.1.3-1 /
+ property name=jetty-jmx value=JettyExtra-1.0.1/jmx /
target name=init unless=build.time
tstamp
@@ -131,10 +132,19 @@
quiet=true
output=catalina.log
/
+echo message=Checking out Jetty/
+cvs cvsRoot=${cvsroot}
+ command=${cvs-op}
+ package=contrib/jetty
+ tag=${version-tag}
+ dest=.
+ quiet=true
+ output=jetty.log
+/
/target
target name=cvs-co
-property name=cvs-op value=co /
+property name=cvs-op value=co -P /
antcall target=do-cvs /
/target
@@ -202,20 +212,36 @@
/target
target name=tomcat4x-dist if=have-tomcat4x depends=check-tomcat
echo message=+++ Building JBoss/Catalina bundle(module=contrib/catalina) /
+pathconvert targetos=unix property=catalina.dist
+ path id=catalina.path
+pathelement location=${tomcat4x} /
+ /path
+/pathconvert
ant antfile=src/build/build.xml dir=contrib/catalina target=bundle
output=catlina.log
- property name=catalina.dist value=${tomcat4x} /
/ant
/target
target name=jetty-dist if=have-jetty depends=check-tomcat
echo message=+++ Building JBoss/Jetty bundle(module=contrib/jetty) /
+pathconvert targetos=unix property=jetty.dist
+ path id=jetty.path
+pathelement location=${jetty} /
+ /path
+/pathconvert
+pathconvert targetos=unix property=jetty.jmx
+ path id=jetty.jmx.path
+pathelement location=${jetty-jmx} /
+ /path
+/pathconvert
ant antfile=src/build/build.xml dir=contrib/jetty target=bundle
output=jetty.log
- property name=jetty.dist value=${jetty} /
/ant
/target
target name=clean
+delete
+ fileset dir=. includes=*.log /
+/delete
ant antfile=src/build/build.xml dir=jboss target=clean /
ant antfile=src/build/build.xml dir=jboss-j2ee target=clean /
ant antfile=src/build/build.xml dir=jnp target=clean /
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/deploy jbosspool-jdbc.rar
User: starksm Date: 01/12/29 02:29:10 Modified:src/etc/deploy Tag: Branch_2_4 jbosspool-jdbc.rar Log: Synch the JBoss_2_4_4 external jars Revision ChangesPath No revision No revision 1.1.4.5 +56 -52jboss/src/etc/deploy/Attic/jbosspool-jdbc.rar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client jboss-j2ee.jar jbossmq-client.jar jbosssx-client.jar jnp-client.jar
User: starksm Date: 01/12/29 02:29:11 Modified:src/client Tag: Branch_2_4 jboss-j2ee.jar jbossmq-client.jar jbosssx-client.jar jnp-client.jar Log: Synch the JBoss_2_4_4 external jars Revision ChangesPath No revision No revision 1.3.4.3 +185 -201 jboss/src/client/Attic/jboss-j2ee.jar Binary file 1.6.4.14 +446 -450 jboss/src/client/Attic/jbossmq-client.jar Binary file 1.8.2.20 +100 -103 jboss/src/client/Attic/jbosssx-client.jar Binary file 1.11.4.7 +24 -21jboss/src/client/Attic/jnp-client.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jboss-j2ee.jar jboss-jaas.jar jboss-jdbc_ext.jar jbosscx.jar jbossmq.jar jbosspool.jar jbosssx.jar jnpserver.jar
User: starksm Date: 01/12/29 02:29:12 Modified:src/lib Tag: Branch_2_4 jboss-j2ee.jar jboss-jaas.jar jboss-jdbc_ext.jar jbosscx.jar jbossmq.jar jbosspool.jar jbosssx.jar jnpserver.jar Log: Synch the JBoss_2_4_4 external jars Revision ChangesPath No revision No revision 1.5.4.3 +185 -201 jboss/src/lib/Attic/jboss-j2ee.jar Binary file 1.11.2.21 +163 -173 jboss/src/lib/Attic/jboss-jaas.jar Binary file 1.2.4.3 +28 -30jboss/src/lib/Attic/jboss-jdbc_ext.jar Binary file 1.1.2.6 +119 -123 jboss/src/lib/Attic/jbosscx.jar Binary file 1.8.4.15 +550 -552 jboss/src/lib/Attic/jbossmq.jar Binary file 1.1.4.7 +238 -238 jboss/src/lib/Attic/jbosspool.jar Binary file 1.11.2.21 +283 -274 jboss/src/lib/Attic/jbosssx.jar Binary file 1.13.4.8 +25 -26jboss/src/lib/Attic/jnpserver.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/build build.xml
User: starksm
Date: 01/12/29 03:04:43
Modified:jetty/src/build Tag: Branch_2_4 build.xml
Log:
Fix copy to bundle dir
Revision ChangesPath
No revision
No revision
1.6.2.5 +3 -6 contrib/jetty/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/src/build/Attic/build.xml,v
retrieving revision 1.6.2.4
retrieving revision 1.6.2.5
diff -u -r1.6.2.4 -r1.6.2.5
--- build.xml 2001/12/29 09:33:04 1.6.2.4
+++ build.xml 2001/12/29 11:04:43 1.6.2.5
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=UTF-8 ?
-!-- $Id: build.xml,v 1.6.2.4 2001/12/29 09:33:04 starksm Exp $ --
+!-- $Id: build.xml,v 1.6.2.5 2001/12/29 11:04:43 starksm Exp $ --
!-- An Ant build file for the jetty-service jar and the
JBoss/Jetty bundle. The buildfile requires a JBoss dist
@@ -130,9 +130,9 @@
fileset dir=${jetty.jmx}/
/copy
-chmod file=${bundle.dir}/jetty/cgi-bin/env.sh perm=+x/
+chmod file=${bundle.root}/jetty/cgi-bin/env.sh perm=+x/
echo message=copying Jetty JMX from ${jetty.jmx} to ${bundle.dir}/jetty-jmx
/
-copy todir=${bundle.dir}/jetty-jmx
+copy todir=${bundle.root}/jetty-jmx
fileset dir=${jetty.jmx}/
/copy
@@ -257,9 +257,6 @@
copy
todir=${build.classes.dir}/WEB-INF/classes/org/jboss/test/tomcat/servlet
fileset dir=${build.classes.dir}/org/jboss/test/tomcat/servlet /
/copy
- !-- copy
todir=${build.classes.dir}/WEB-INF/classes/org/jboss/test/tomcat/ejb/interfaces
- fileset dir=${build.classes.dir}/org/jboss/test/tomcat/ejb/interfaces /
- /copy --
jar jarfile=${build.classes.dir}/${test.client}.war
basedir=${build.classes.dir}
manifest=${src.resources}/web.mf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: starksm Date: 01/12/29 03:10:37 Modified:.Tag: Branch_2_4 build.xml Log: Add jetty-dist to dist target Revision ChangesPath No revision No revision 1.33.2.8 +1 -0 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.33.2.7 retrieving revision 1.33.2.8 diff -u -r1.33.2.7 -r1.33.2.8 --- build.xml 2001/12/29 10:22:38 1.33.2.7 +++ build.xml 2001/12/29 11:10:37 1.33.2.8 @@ -198,6 +198,7 @@ ant antfile=src/build/build.xml dir=jboss target=dist-zip / antcall target=tomcat3x-dist / antcall target=tomcat4x-dist / +antcall target=jetty-dist / /target target name=tomcat3x-dist if=have-tomcat3x depends=check-tomcat echo message=+++ Building JBoss/Tomcat bundle(module=contrib/tomcat) / ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HttpSessions: distributed locking
Hi, as far as I know WAS 3.0/3.5 does. You can turn a switch and Websphere will synchronize every http session access accross the cluster using the underlying database. This results obviously in a huge performance penalty. I don't remember WAS having a switch to tell it, that it is being used with a session-aware dispatching mechanism. You can just use the switch to synchronize state/lock with the database. As far as I remember it is called something like use in a cluster. A working in a session-aware environment switch could be nice for JBoss in order to prevent all the overhead involved in locking, when only one node is accessed anyway. Just for the sake of the full picture. I rememeber that everytime you access the http-session a lock is created and when you leave the service method the lock is released. IBM provides also an interface with a method sync() to release it earlier. I haven't worked with Websphere for more than a year now (being 3.5 the last version I was working with), but I don't think that they found the silver bullet and I assume it is still working that way, but don't know for sure. Anyway my knowledge is not sharp as a pencil anymore, maybe I got some of the details wrong. Mariano -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey Sent: Saturday, December 29, 2001 10:24 AM To: Bill Burke; Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] HttpSessions: distributed locking Bill, That is really interesting. Furthermore, for BEA, remember that thanks to their front-end dispatcher, it is always the same server that will receive the invocations (until it fails). Consequently, they don't need distributed locking because until a server dies, there is no distributed state anyway (I mean state that is used on different nodes, state is only replicated but replicas are not used) Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Bill Burke Envoyé : vendredi, 28 décembre 2001 22:14 À : Jboss-Development@Lists. Sourceforge. Net Objet : [JBoss-dev] HttpSessions: distributed locking Weblogic doesn't seem to support concurrent access to clustered HttpSessions. Maybe it is all right for us to be this lazy too. Applications Using Frames Must Coordinate Session Access If you are designing a Web application that utilizes multiple frames, keep in mind that there is no synchronization of requests made by frames in a given frameset. For example, it is possible for multiple frames in a frameset to create multiple sessions on behalf of the client application, even though the client should logically create only a single session. In a clustered environment, poor coordination of frame requests can cause unexpected application behavior. For example, multiple frame requests can reset the application's association with a clustered instance, because the proxy plug-in treats each request independently. It is also possible for an application to corrupt session data by modifying the same session attribute via multiple frames in a frameset. To avoid unexpected application behavior, always use careful planning when accessing session data with frames. You can apply one of the following general rules to avoid common problems: In a given frameset, ensure that only one frame creates and modifies session data. Always create the session in a frame of the first frameset your application uses (for example, create the session in the first HTML page that is visited). After the session has been created, access the session data only in framesets other than the first frameset. ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp
User: starksm Date: 01/12/29 03:41:56 Modified:src/docs binary.jsp Log: Update the 2.4.4 links Revision ChangesPath 1.22 +18 -17newsite/src/docs/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- binary.jsp2001/12/12 03:39:22 1.21 +++ binary.jsp2001/12/29 11:41:56 1.22 @@ -1,3 +1,4 @@ + jsp:include page=head.jsp flush=true / jsp:include page=slogan.jsp flush=true jsp:param name=SLOGAN value=BINARIES/ @@ -26,10 +27,10 @@ p class=headDOWNLOAD THE JBOSS SERVER PRODUCTS TODAY!/p p class=text - JBoss 2.4.4 is our current bbeta/b version. It will run on 1.3+ JVMs. + JBoss 3.0.0 is our current balpha, unstable/b version. It will run on 1.3+ JVMs. p class=text - JBoss 2.4.3 is our current bstable/b version. It will run on 1.3+ JVMs. - + JBoss 2.4.4 is our current bstable/b version. It will run on 1.3+ JVMs. + p class=text This is our full suite of products and it is likely to be all you will need to try out our technology. If you need a servlet container, we @@ -66,29 +67,29 @@ thp class=textDate/th/tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4-beta.zip;JBoss-2.4.4-beta.zip/a/td -td align=rightp class=text8,980,992/td -td align=centerp class=textDecember 10, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4.zip;JBoss-2.4.4.zip/a/td +td align=rightp class=text8,821,782/td +td align=centerp class=textDecember 29, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4-src.tgz;JBoss-2.4.4-src.tgz Src Archive/a/td -td align=rightp class=text23,765,628/td -td align=centerp class=textDecember 11, 2001/td +td align=rightp class=text24,450,351/td +td align=centerp class=textDecember 29, 2001/td /tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-4.0.1-beta.zip;JBoss-2.4.4_Tomcat-4.0.1-beta.zip/a/td -td align=rightp class=text14,325,316/td -td align=centerp class=textDecember 10, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-4.0.1.zip;JBoss-2.4.4_Tomcat-4.0.1.zip/a/td +td align=rightp class=text14,187,146/td +td align=centerp class=textDecember 29, 2001/td /tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-3.2.3-beta.zip;JBoss-2.4.4_Tomcat-3.2.3-beta.zip/a/td -td align=rightp class=text12,311,220/td -td align=centerp class=textDecember 10, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-3.2.3.zip;JBoss-2.4.4_Tomcat-3.2.3.zip/a/td +td align=rightp class=text12,167,307/td +td align=centerp class=textDecember 29, 2001/td /tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Jetty-3.1.3-1-beta.zip;JBoss-2.4.4_Jetty-3.1.3-1-beta.zip/a/td -td align=rightp class=text12,783,258/td -td align=centerp class=textDecember 10, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Jetty-3.1.3-1.zip;JBoss-2.4.4_Jetty-3.1.3-1.zip/a/td +td align=rightp class=text9,959,926/td +td align=centerp class=textDecember 29, 2001/td /tr trth colspan=3 bgcolor=#008000/th ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] postgresql-service.xml
I'm trying to deploy the new petstore v1.3 to JBoss 3.0. I've found the JDBC data source configuration has changed considerably from JBoss 2.4. Any documentation or examples that would help in creating a postgresql-service.xml file would be greatly appreciated. -Michael Robinson ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/interfaces DistributedState.java
User: slaboure Date: 01/12/29 08:09:41 Modified:src/main/org/jboss/ha/framework/interfaces DistributedState.java Log: - possibility to know if a modification has been done locally or initiated from another node - remove now returns the old value Revision ChangesPath 1.5 +4 -4 jbossmx/src/main/org/jboss/ha/framework/interfaces/DistributedState.java Index: DistributedState.java === RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/interfaces/DistributedState.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- DistributedState.java 2001/11/26 14:58:26 1.4 +++ DistributedState.java 2001/12/29 16:09:41 1.5 @@ -27,7 +27,7 @@ * modified/removed/added in a particular category. * * @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a. - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ * * pbRevisions:/bbr * @see HAPartition @@ -47,7 +47,7 @@ * @param key The key that has been added or its value modified * @param value The new value of the key */ - public void valueHasChanged (String category, String key, Serializable value); + public void valueHasChanged (String category, String key, Serializable value, boolean locallyModified); /** * Called whenever a key has been removed from a category the called object had * subscribed in. @@ -55,7 +55,7 @@ * @param key The key that has been removed * @param previousContent The previous content of the key that has been removed */ - public void keyHasBeenRemoved (String category, String key, Serializable previousContent); + public void keyHasBeenRemoved (String category, String key, Serializable previousContent, boolean locallyModified); } /** @@ -116,5 +116,5 @@ * @param key Key to be removed * @throws Exception if a network exception occurs while removing the entry. */ - public void remove (String category, String key) throws Exception; + public Serializable remove (String category, String key) throws Exception; } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server DistributedStateImplMBean.java
User: slaboure
Date: 01/12/29 08:10:10
Added: src/main/org/jboss/ha/framework/server
DistributedStateImplMBean.java
Log:
DistributedStateImpl is now a standard MBean
Revision ChangesPath
1.1
jbossmx/src/main/org/jboss/ha/framework/server/DistributedStateImplMBean.java
Index: DistributedStateImplMBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ha.framework.server;
/**
* description
*
* @see related
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
* @version $Revision: 1.1 $
*
* pbRevisions:/b
*
* pb29. décembre 2001 Sacha Labourey:/b
* ul
* li First implementation /li
* /ul
*/
public interface DistributedStateImplMBean extends
org.jboss.ha.framework.interfaces.DistributedState
{
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server DistributedStateImpl.java
User: slaboure
Date: 01/12/29 08:11:43
Modified:src/main/org/jboss/ha/framework/server
DistributedStateImpl.java
Log:
- possibility to know if a modification has been done locally or initiated from
another node
- remove now returns the old value
- DistributedStateImpl is now registred as a standard MBean
- we no more use asynch calls (usefull for HTTPSession clustering). This should be
made optional by the user code
Revision ChangesPath
1.5 +55 -16
jbossmx/src/main/org/jboss/ha/framework/server/DistributedStateImpl.java
Index: DistributedStateImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/DistributedStateImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DistributedStateImpl.java 2001/11/26 15:04:50 1.4
+++ DistributedStateImpl.java 2001/12/29 16:11:43 1.5
@@ -15,6 +15,9 @@
import java.util.Vector;
import java.rmi.server.UnicastRemoteObject;
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+
import org.jboss.ha.framework.interfaces.DistributedState.DSListener;
import org.jboss.ha.framework.interfaces.HAPartition.HAPartitionStateTransfer;
import org.jboss.ha.framework.interfaces.HAPartition.HAMembershipListener;
@@ -26,7 +29,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* pbRevisions:/bbr
* pb2001/11/26: Sacha Labourey/b
@@ -36,7 +39,7 @@
* /ol
*/
public class DistributedStateImpl
-implements DistributedState, HAPartitionStateTransfer
+implements DistributedStateImplMBean, HAPartitionStateTransfer
{
// Constants -
@@ -49,14 +52,19 @@
protected HAPartition partition;
protected org.jboss.logging.Logger log = null;
+
+ protected MBeanServer mbeanServer = null;
- // Static
+ // Static c
// Constructors --
- public DistributedStateImpl (HAPartition partition)
+ public DistributedStateImpl () {} // for JMX checks
+
+ public DistributedStateImpl (HAPartition partition, MBeanServer server)
{
this.partition = partition;
+ this.mbeanServer = server;
this.log = org.jboss.logging.Logger.getLogger (this.getClass ());
}
@@ -68,7 +76,18 @@
// this service.
//
partition.subscribeToStateTransferEvents (SERVICE_NAME, this);
- partition.registerRPCHandler (SERVICE_NAME, this);
+ partition.registerRPCHandler (SERVICE_NAME, this);
+
+ // subscribed this sub-service of HAPartition with JMX
+ // TODO: In the future (when state transfer issues will be completed),
+ // we will need to redesign the way HAPartitions and its sub-protocols are
+ // registered with JMX. They will most probably be independant JMX services.
+ //
+ String name = JBOSS-SYSTEM:service= + SERVICE_NAME +
+,partitionName= + this.partition.getPartitionName();
+ ObjectName jmxName = new ObjectName(name);
+ mbeanServer.registerMBean(this, jmxName);
+ org.jboss.system.Registry.bind (name, this);
}
public void start () throws Exception
@@ -77,6 +96,9 @@
public void stop () throws Exception
{
+ String name = JBOSS-SYSTEM:service= + SERVICE_NAME +
+,partitionName= + this.partition.getPartitionName();
+ org.jboss.system.Registry.unbind (name);
}
// DistributedState implementation --
@@ -85,15 +107,21 @@
{
Object[] args =
{category, key, value};
- partition.callAsynchMethodOnCluster (SERVICE_NAME, _set, args, false);
+ partition.callMethodOnCluster (SERVICE_NAME, _set, args, true);
+ this._setInternal (category, key, value);
+ notifyKeyListeners (category, key, value, true);
}
- public void remove (String category, String key) throws Exception
+ public Serializable remove (String category, String key) throws Exception
{
Object[] args =
{category, key};
- partition.callAsynchMethodOnCluster (SERVICE_NAME, _remove, args, false);
+ partition.callMethodOnCluster (SERVICE_NAME, _remove, args, true);
+
+ Serializable removed = this._removeInternal (category, key);
+ notifyKeyListenersOfRemove (category, key, removed , true);
+
Re: [JBoss-dev] What the point?
I read the description on your web site, and get very excited about the product. But when I try and use the JBoss 3.0 alpha, I am wondering why you not spend any time on the web container? J2EE container without a servlet engine is like a book without writing. Also, you guy seem to reinvent entire product every version. Every version is big description about how powerful and wonderful this is. Then next version, all that thrown out and you rewrite every thing. who is this buffon? what is the point of what the point __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6351 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server ClusterPartition.java HAPartitionImpl.java
User: slaboure
Date: 01/12/29 08:20:13
Modified:src/main/org/jboss/ha/framework/server ClusterPartition.java
HAPartitionImpl.java
Log:
Propagate MBeanServer reference
Revision ChangesPath
1.9 +2 -2
jbossmx/src/main/org/jboss/ha/framework/server/ClusterPartition.java
Index: ClusterPartition.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/ClusterPartition.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ClusterPartition.java 2001/11/26 15:52:55 1.8
+++ ClusterPartition.java 2001/12/29 16:20:12 1.9
@@ -23,7 +23,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a.
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*
* pbRevisions:/bbr
*/
@@ -138,7 +138,7 @@
channel.SetOpt(Channel.AUTO_GETSTATE, new Boolean(true));
log.info(Creating HAPartition...);
- partition = new HAPartitionImpl(partitionName, channel, deadlock_detection);
+ partition = new HAPartitionImpl(partitionName, channel, deadlock_detection,
getServer());
log.info(...Initing HAPartition...);
partition.init();
1.11 +11 -2
jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
Index: HAPartitionImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- HAPartitionImpl.java 2001/11/26 14:20:01 1.10
+++ HAPartitionImpl.java 2001/12/29 16:20:13 1.11
@@ -14,6 +14,7 @@
import javax.naming.Context;
import javax.naming.StringRefAddr;
import javax.naming.InitialContext;
+import javax.management.MBeanServer;
import JavaGroups.MethodCall;
@@ -32,7 +33,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a.
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*
* pbRevisions:/bbr
*/
@@ -65,10 +66,18 @@
protected long currentViewId = -1;
+ protected MBeanServer server = null;
+
// Static
// Constructors --
+ public HAPartitionImpl (String partitionName, JavaGroups.JChannel channel,
boolean deadlock_detection, MBeanServer server) throws Exception
+ {
+ this (partitionName, channel, deadlock_detection);
+ this.server = server;
+ }
+
public HAPartitionImpl (String partitionName, JavaGroups.JChannel channel,
boolean deadlock_detection) throws Exception
{
super(channel, null, null, new Object (), false); // init RpcDispatcher with
a fake target object
@@ -99,7 +108,7 @@
// Create the DS and link it to this HAPartition
//
log.debug (create distributed state);
- this.dsManager = new DistributedStateImpl (this);
+ this.dsManager = new DistributedStateImpl (this, this.server);
log.debug (init distributed state service);
this.dsManager.init ();
log.debug (bind distributed state service);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins CMPClusteredInMemoryPersistenceManager.java
User: slaboure
Date: 01/12/29 08:21:32
Added: src/main/org/jboss/ejb/plugins
CMPClusteredInMemoryPersistenceManager.java
Log:
Clustered In-memory persistence manager based on DistributedState (itself based on
HAPartition)
Revision ChangesPath
1.1
jbossmx/src/main/org/jboss/ejb/plugins/CMPClusteredInMemoryPersistenceManager.java
Index: CMPClusteredInMemoryPersistenceManager.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.io.IOException;
import java.util.ArrayList;
import javax.ejb.EJBException;
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.util.FinderResults;
import org.jboss.ha.framework.interfaces.DistributedState;
/**
* EntityPersistenceStore implementation storing values in-memory
* and shared accross the cluster through the DistributedState service
* from the clustering framework. It always uses the DefaultPartition.
*
* @see org.jboss.ejb.EntityPersistenceStore
* @see org.jboss.ejb.plugins.CMPInMemoryPersistenceManager
* @see org.jboss.ha.framework.interfaces.DistributedState
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
* @version $Revision: 1.1 $
*
* pbRevisions:/b
*
* pb29.12.2001 - Sacha Labourey:/b
* ul
* li First implementation highly based on CMPInMemoryPersistenceManager/li
* /ul
*/
public class CMPClusteredInMemoryPersistenceManager implements
org.jboss.ejb.EntityPersistenceStore
{
// Constants -
// Attributes
protected org.jboss.ejb.EntityContainer con = null;
protected Field idField = null;
protected DistributedState ds = null;
protected String DS_CATEGORY = null;
/**
* Optional isModified method used by storeEntity
*/
protected Method isModified = null;
// Static
// Constructors --
public CMPClusteredInMemoryPersistenceManager ()
{
}
/**
* create the service, do expensive operations etc
*/
public void create () throws Exception
{
String name =
JBOSS-SYSTEM:service=DistributedState,partitionName=DefaultPartition;
ds = (DistributedState)org.jboss.system.Registry.lookup (name);
String ejbName = con.getBeanMetaData ().getEjbName ();
this.DS_CATEGORY = CMPClusteredInMemoryPersistenceManager- + ejbName;
idField = con.getBeanClass ().getField (id);
try
{
isModified = con.getBeanClass ().getMethod (isModified, new Class[0]);
if (!isModified.getReturnType ().equals (Boolean.TYPE))
isModified = null; // Has to have boolean as return type!
}
catch (NoSuchMethodException ignored)
{}
}
/**
* start the service, create is already called
*/
public void start () throws Exception
{
}
/**
* This callback is set by the container so that the plugin may access it
*
* @param conThe container using this plugin.
*/
public void setContainer (org.jboss.ejb.Container con)
{
this.con = (org.jboss.ejb.EntityContainer)con;
}
/**
* stop the service
*/
public void stop ()
{
}
/**
* destroy the service, tear down
*/
public void destroy ()
{
}
// Public
// EntityPersistenceStore implementation
--
/**
* Returns a new instance of the bean class or a subclass of the bean class.
*
* @return the new instance
*
* @throws Exception
*/
public Object createBeanClassInstance () throws Exception
{
return con.getBeanClass ().newInstance ();
}
/**
* Initializes the instance context.
*
* pThis method is called before createEntity, and should
* reset the value of all cmpFields to 0 or null.
*
* @param ctx
*
* @throws RemoteException
*/
public void initEntity (EntityEnterpriseContext ctx)
{
// first get cmp metadata of this entity
Object instance = ctx.getInstance ();
Class ejbClass = instance.getClass ();
Field cmpField;
Class cmpFieldType;
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins ClusterSyncEntityInstanceCache.java
User: slaboure
Date: 01/12/29 08:23:11
Added: src/main/org/jboss/ejb/plugins
ClusterSyncEntityInstanceCache.java
Log:
Entity Instance cache for clustered environment with distributed cache
synchronization: if a bean is modified on another host, all other distributed cache
clean this bean from their cache.
Revision ChangesPath
1.1
jbossmx/src/main/org/jboss/ejb/plugins/ClusterSyncEntityInstanceCache.java
Index: ClusterSyncEntityInstanceCache.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins;
import java.rmi.RemoteException;
import java.rmi.NoSuchObjectException;
import org.jboss.ejb.Container;
import org.jboss.ejb.EntityContainer;
import org.jboss.ejb.CacheKey;
import org.jboss.ejb.EnterpriseContext;
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.util.Sync;
import org.jboss.ha.framework.interfaces.DistributedState;
/**
* Cache subclass for entity beans shared accross a cluster with
* distributed cache corruption mechanism.
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
* @version $Revision: 1.1 $
*/
public class ClusterSyncEntityInstanceCache
extends EntityInstanceCache
implements org.jboss.ha.framework.interfaces.DistributedState.DSListener
{
// Constants -
// Attributes
protected DistributedState ds = null;
protected String DS_CATEGORY = null;
// Static
// Constructors --
// Public
public void create() throws Exception
{
super.create ();
// Get a reference to the DS service
//
String name =
JBOSS-SYSTEM:service=DistributedState,partitionName=DefaultPartition;
ds = (DistributedState)org.jboss.system.Registry.lookup (name);
}
public void start() throws Exception
{
super.start ();
String ejbName = this.getContainer ().getBeanMetaData ().getEjbName ();
this.DS_CATEGORY = CMPClusteredInMemoryPersistenceManager- + ejbName;
this.ds.registerDSListener (this.DS_CATEGORY, this);
}
/* From Service interface*/
public void stop()
{
super.stop ();
this.ds.unregisterDSListener (this.DS_CATEGORY, this);
}
// DSListener implementation -
/**
* Called whenever a key has been removed from a category the called object had
* subscribed in.
* @param category The category under which a key has been removed
* @param key The key that has been removed
* @param previousContent The previous content of the key that has been removed
*/
public void keyHasBeenRemoved (String category, String key, java.io.Serializable
previousContent, boolean locallyModified)
{
if (!locallyModified)
this.cacheMiss (key);
}
/**
* Called whenever a key has been added or modified in the category the called
object
* has subscribed in.
* @param category The category of the modified/added entry
* @param key The key that has been added or its value modified
* @param value The new value of the key
*/
public void valueHasChanged (String category, String key, java.io.Serializable
value, boolean locallyModified)
{
if (!locallyModified)
this.cacheMiss (key);
}
// Package protected -
// Protected -
public void cacheMiss (String key)
{
// a modification has occured on another node, we clean the cache!
//
try
{
this.remove (key);
}
catch (Exception e)
{
e.printStackTrace ();
}
}
// Private ---
// Inner classes -
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't use EJBs for HttpSessions.
implement HttpSessions. Maybe I'm getting too religious here (meaning too EJB spec oriented), but EJB semantics require that input parameters and return parameters be serialized(copied). Sure, JBoss doesn't do this by default, but maybe some users turn off this optimization to be EJB Spec The user can not turn this optimization off since this is a container for the http sessions only. ok look i am tired of talking, marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6221 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: RE: [JBoss-dev] distributed HttpSessions - advice...
Look there might be more than one way to skin this cat, I am of the opinion that the EJB solution, can be completely simple and transparent, the semantic that julian requested was a findbyprimary key that maps trivially to the ejb framework. it is up to us to show that the container can be dedicated *using the distributed hastable* as the persistence (load and store would be get and set on the whole object, the object being the http session). I want to prove that EJB is a distributed SYSTEM construct, the moment we start seeing transactions accessing these stores (session) we would be able to include these trivially. So give me a chance to prove that point, something tells me that the EJB bashing is a by product of ignorance and strict spec interpretation. That said, all you really need is a distributed hashtable. There's already one implemented as the Distributed State Service. No coding, this is already done. Can't get more simpler than that. Implement an HttpSession as a serializable object. get the session from the DSS at the beginning of an HTTP request, put the session back into the DSS at the end of the request. Simple as that. Well at least for the 1st iteration :) slow down cowboy, you have been going fast these last days, you still need the finder semantic that Julian is asking for, not that it is complex but it stills needs to be there and it if you use EJB it is free and julian can work on it right now while we use the DSS to replicate the state with the code you have already written, the fancy invm cache we were talking about with Sacha can be your first iteration distributed hashtable. 2. Also, sub-partitioning should really be handled at the HAPartition level and should be totally transparent to every other clustering feature/service. Configuring sub-partition sizes and whether automatic-sub-partitioning should be turned on or not should been done solely in the HAPartition MBean. don't worry about this at first, the automatic topology partitioning is fancy but I don't foresee needing it immediately. 3. I think the complexity starts to become a factor when you start thinking about concurrent access to HttpSessions. IMHO, it is quite common to have 2 different HTTP requests accessing the same HTTP session concurrently. I think you're going to need some sort of distributed locking for HTTPSessions otherwise people are going to come across some really funky errors when they start using this stuff. Of course, you don't need distributed locking if you require the load-balancer to give you sticky sessions. Yes and this can be abstracted UNDER the EJB hood, marcf Bill Bill, let this be, if I am wrong I will eat my words, but I something tells me this is what EJBs were really given to us for, heck I remember Vlada Matena pitching sessions and entity at the same level (user constructs) to SAP. i.e. not even these guys saw the system potential of the EJB construct, tweaking the persistence and putting a custom interceptor stack (no security says Julian...ok) would really prove the point in spades, I think, let me try it. marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6221 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] emacs template for JBoss
Does anybody have one? My laptop just got stolen, and it took me forever to ah man that really sucks... sounds like my pinus just got ran over by a train, ouch ouch when you have it let's make sure it is included in the doco somewhere, marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6328 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] emacs template for JBoss
Bill, sorry to post publicly but I am in Miami typing on an interim laptop until I set up my machine. My wife tells me that since you are consulting with JBoss Group as an independent you can declare this as a loss against income earned and if you buy a new one it is a business expense. Don't forget January 15th/16th tax quaterly tax filing (trust the woman, I do :) really sorry to hear about your loss, but it is a good excuse to upgrade, now if only you would steal mine like we discussed earlier, it craps out on outlook only, cheers, marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6328 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cluster-wide logging
Another case... what about a log4j EJB logger that logs centrally, the CMP engine can be something as simple as a file writter or as fancy as a JDBC writter so you can plug in what you want for the persistence. So for the price of writing the EJB logger we have the cluster wide logging for free with pluggable persistence I feel crusadish this week marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6335 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/test ConnectionUnitTestCase.java
User: chirino
Date: 01/12/29 09:42:02
Modified:src/main/org/jboss/test/jbossmq/test
ConnectionUnitTestCase.java
Log:
Added a test to see if 10 back to back connections to the server caused any errors
Revision ChangesPath
1.3 +91 -69
jbosstest/src/main/org/jboss/test/jbossmq/test/ConnectionUnitTestCase.java
Index: ConnectionUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/test/ConnectionUnitTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ConnectionUnitTestCase.java 2001/11/11 00:18:39 1.2
+++ ConnectionUnitTestCase.java 2001/12/29 17:42:02 1.3
@@ -22,80 +22,102 @@
* established with JBossMQ
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class ConnectionUnitTestCase extends JBossTestCase {
- public ConnectionUnitTestCase(String name) {
- super(name);
- }
+ public ConnectionUnitTestCase(String name) {
+ super(name);
+ }
- protected void setUp() throws Exception {
- }
+ protected void setUp() throws Exception {
+ }
- public void testOILConnectViaJNDI() throws Exception {
- InitialContext ctx = new InitialContext();
-
- QueueConnectionFactory cf =
(QueueConnectionFactory)ctx.lookup(ConnectionFactory);
- QueueConnection c = cf.createQueueConnection();
- c.close();
-
- XAQueueConnectionFactory xacf =
(XAQueueConnectionFactory)ctx.lookup(XAConnectionFactory);
- XAQueueConnection xac = xacf.createXAQueueConnection();
- xac.close();
- }
-
- public void testOILConnectNoJNDI() throws Exception {
-
- Properties props = new Properties();
- props.setProperty(OILServerILFactory.SERVER_IL_FACTORY_KEY,
OILServerILFactory.SERVER_IL_FACTORY);
- props.setProperty(OILServerILFactory.CLIENT_IL_SERVICE_KEY,
OILServerILFactory.CLIENT_IL_SERVICE);
- props.setProperty(OILServerILFactory.PING_PERIOD_KEY, 1000);
- props.setProperty(OILServerILFactory.OIL_ADDRESS_KEY, localhost);
- props.setProperty(OILServerILFactory.OIL_PORT_KEY,8090);
-
- QueueConnectionFactory cf = new SpyConnectionFactory(props);
- QueueConnection c = cf.createQueueConnection();
- c.close();
-
- XAQueueConnectionFactory xacf = new SpyXAConnectionFactory(props);
- XAQueueConnection xac = xacf.createXAQueueConnection();
- xac.close();
-
- }
-
- public void testUILConnectViaJNDI() throws Exception {
- InitialContext ctx = new InitialContext();
-
- QueueConnectionFactory cf =
(QueueConnectionFactory)ctx.lookup(UILConnectionFactory);
- QueueConnection c = cf.createQueueConnection();
- c.close();
-
- XAQueueConnectionFactory xacf =
(XAQueueConnectionFactory)ctx.lookup(UILXAConnectionFactory);
- XAQueueConnection xac = xacf.createXAQueueConnection();
- xac.close();
- }
-
- public void testUILConnectNoJNDI() throws Exception {
-
- Properties props = new Properties();
- props.setProperty(UILServerILFactory.SERVER_IL_FACTORY_KEY,
UILServerILFactory.SERVER_IL_FACTORY);
- props.setProperty(UILServerILFactory.CLIENT_IL_SERVICE_KEY,
UILServerILFactory.CLIENT_IL_SERVICE);
- props.setProperty(UILServerILFactory.PING_PERIOD_KEY, 1000);
- props.setProperty(UILServerILFactory.UIL_ADDRESS_KEY, localhost);
- props.setProperty(UILServerILFactory.UIL_PORT_KEY,8091);
-
- QueueConnectionFactory cf = new SpyConnectionFactory(props);
- QueueConnection c = cf.createQueueConnection();
- c.close();
+ public void testMultipleOILConnectViaJNDI() throws Exception {
+
+ getLog().debug(Starting testMultipleOILConnectViaJNDI);
+
+ InitialContext ctx = new InitialContext();
+
+ QueueConnectionFactory cf = (QueueConnectionFactory)
ctx.lookup(ConnectionFactory);
+
+ QueueConnection connections[] = new QueueConnection[10];
- XAQueueConnectionFactory xacf = new SpyXAConnectionFactory(props);
- XAQueueConnection xac = xacf.createXAQueueConnection();
- xac.close();
- }
+ getLog().debug(Creating +connections.length+ connections.);
+ for( int i=0; i
Re: [JBoss-dev] postgresql-service.xml
Consult the online manual, ch 3. david jencks On 2001.12.29 09:58:22 -0500 Michael Robinson wrote: I'm trying to deploy the new petstore v1.3 to JBoss 3.0. I've found the JDBC data source configuration has changed considerably from JBoss 2.4. Any documentation or examples that would help in creating a postgresql-service.xml file would be greatly appreciated. -Michael Robinson ___ 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
[JBoss-dev] Why are we using RollingFileAppender in RH?
I am curious, why we are using the RollingFileAppender in JBoss 3 alpha? With the amount of logging that happens by default, the log fills up very quickly, and the logfile gets rolled over. The problem is, since log4j actually renames the file, and creates a new one, any instance of tail server.log running, will still be watching the old inode (the backed up version). So you have to re-tail the file every few minutes. I understand using it for production purposes to save disk space, but in the Alpha version it seems kind of silly, and a pain to the developer trying to watch what's going on. Anyone mind if I switch it over? (just comment out the rolling stuff, so people who want it could put it back) I assume who ever made it this way was on windows, where the cygwin tail would have no problem watching the new file. But that doesn't work on *NIX machines. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] sar problems
I'm trying to convert my postgres-ds-service.xml file into a sar, so I don't have to copy the jar and then the service file. I created a sar file with my previous service file at META-INF/jboss-service.xml and the postgres jar (jdbc7.0-1.2.jar) in the root of the sar. Now when I copy the jar to the deploy directory, I get an exception about not being able to find the jdbc7.0-1.2.jar file. In my jboss-service.xml file I have the following xml: server classpath archives=jdbc7.0-1.2.jar/ /server Do I need to add something to the archives tag to tell it to look in the current sar? I there a way to integrate my sar into an ear? Thanks, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why are we using RollingFileAppender in RH?
I have been changing the log size to 10MB. If you don't have 10MB on your development machine, you have much bigger problems. -dain -Original Message- From: David Budworth [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 1:21 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Why are we using RollingFileAppender in RH? I am curious, why we are using the RollingFileAppender in JBoss 3 alpha? With the amount of logging that happens by default, the log fills up very quickly, and the logfile gets rolled over. The problem is, since log4j actually renames the file, and creates a new one, any instance of tail server.log running, will still be watching the old inode (the backed up version). So you have to re-tail the file every few minutes. I understand using it for production purposes to save disk space, but in the Alpha version it seems kind of silly, and a pain to the developer trying to watch what's going on. Anyone mind if I switch it over? (just comment out the rolling stuff, so people who want it could put it back) I assume who ever made it this way was on windows, where the cygwin tail would have no problem watching the new file. But that doesn't work on *NIX machines. -David ___ 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
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss_2_4.dtd
User: starksm Date: 01/12/29 11:50:07 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jboss_2_4.dtd Log: Add the strictMaximumSize and strictTimeout container-pool-conf child elements Revision ChangesPath No revision No revision 1.1.2.10 +23 -3 jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd Index: jboss_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd,v retrieving revision 1.1.2.9 retrieving revision 1.1.2.10 diff -u -r1.1.2.9 -r1.1.2.10 --- jboss_2_4.dtd 2001/11/28 06:25:28 1.1.2.9 +++ jboss_2_4.dtd 2001/12/29 19:50:07 1.1.2.10 @@ -7,8 +7,8 @@ -//JBoss//DTD JBOSS 2.4//EN http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd; -$Id: jboss_2_4.dtd,v 1.1.2.9 2001/11/28 06:25:28 starksm Exp $ -$Revision: 1.1.2.9 $ +$Id: jboss_2_4.dtd,v 1.1.2.10 2001/12/29 19:50:07 starksm Exp $ +$Revision: 1.1.2.10 $ Overview of the architecture of jboss.xml @@ -699,7 +699,7 @@ Used in: container-configuration -- -!ELEMENT container-pool-conf ((MaximumSize , MinimumSize) | Synchronized) +!ELEMENT container-pool-conf ((MaximumSize , MinimumSize, strictMaximumSize?, strictTimeout?) | Synchronized) !-- This element is only valid if the instance pool is a subclass of @@ -722,6 +722,26 @@ Used in: container-pool-conf for AbstractInstancePool subclasses -- !ELEMENT MinimumSize (#PCDATA) + +!-- This element is used by AbstractInstancePool subclasses to enforce +strict adherence to the InstancePool MaximumSize bound. It is a boolean flag +flag that when true, will only allow MaximumSize ejb instances to be active +rather than allowing non-pool instances to be created as needed. When +there are MaximumSize active instances, any subsequent requests will be +blocked until an instance is freed back to the pool. The default +value for this element is false. +-- +!ELEMENT strictMaximumSize (#PCDATA) + +!-- This element is used by AbstractInstancePool subclasses to set the time +in milliseconds to wait for an instance to be returned to the pool when there +are MaximumSize active instances. A value less than or equal to 0 will mean +not to wait at all. When a request times out waiting for an instance a +java.rmi.ServerException is generated and the call aborted. This is parsed +as an Integer so that max wait time is 2147483647 or just under 25 days, and +this is the default value. +-- +!ELEMENT strictTimeout (#PCDATA) !-- This element is only valid if the instance pool is ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using RollingFileAppender in RH?
Either crank up the default log size or fix the excessive logging by adjusting the priorities being used. - Original Message - From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 11:20 AM Subject: [JBoss-dev] Why are we using RollingFileAppender in RH? I am curious, why we are using the RollingFileAppender in JBoss 3 alpha? With the amount of logging that happens by default, the log fills up very quickly, and the logfile gets rolled over. The problem is, since log4j actually renames the file, and creates a new one, any instance of tail server.log running, will still be watching the old inode (the backed up version). So you have to re-tail the file every few minutes. I understand using it for production purposes to save disk space, but in the Alpha version it seems kind of silly, and a pain to the developer trying to watch what's going on. Anyone mind if I switch it over? (just comment out the rolling stuff, so people who want it could put it back) I assume who ever made it this way was on windows, where the cygwin tail would have no problem watching the new file. But that doesn't work on *NIX machines. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using RollingFileAppender in RH?
Can we set it to roll on a day to day basis? This would be more useful in a production environment (where an admin would want to see the logs for the entire day). I think that tail -f on most Linux machines will do the right thing. Most certainly on Solaris it will not. Either way we should set it to roll every day or disable rolling altogether. --jason - Original Message - From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 11:20 AM Subject: [JBoss-dev] Why are we using RollingFileAppender in RH? I am curious, why we are using the RollingFileAppender in JBoss 3 alpha? With the amount of logging that happens by default, the log fills up very quickly, and the logfile gets rolled over. The problem is, since log4j actually renames the file, and creates a new one, any instance of tail server.log running, will still be watching the old inode (the backed up version). So you have to re-tail the file every few minutes. I understand using it for production purposes to save disk space, but in the Alpha version it seems kind of silly, and a pain to the developer trying to watch what's going on. Anyone mind if I switch it over? (just comment out the rolling stuff, so people who want it could put it back) I assume who ever made it this way was on windows, where the cygwin tail would have no problem watching the new file. But that doesn't work on *NIX machines. -David ___ 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
[JBoss-dev] [ jboss-Change Notes-497673 ] Support for strict EJB pooling added
Change Notes item #497673, was opened at 2001-12-29 11:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=497673group_id=22866 Category: JBossServer Group: v2.4.4 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: Support for strict EJB pooling added Initial Comment: Support for a stricter EJB pooling policy has been added. Two new container-pool-conf child elements have been added: strictMaximumSize: used by AbstractInstancePool subclasses to enforce strict adherence to the InstancePool MaximumSize bound. It is a boolean flag flag that when true, will only allow MaximumSize ejb instances to be active rather than allowing non-pool instances to be created as needed. When there are MaximumSize active instances, any subsequent requests will be blocked until an instance is freed back to the pool. The default value for this element is false. strictTimeout: used by AbstractInstancePool subclasses to set the time in milliseconds to wait for an instance to be returned to the pool when there are MaximumSize active instances. A value less than or equal to 0 will mean not to wait at all. When a request times out waiting for an instance a java.rmi.ServerException is generated and the call aborted. This is parsed as an Integer so that max wait time is 2147483647 or just under 25 days, and this is the default value. These values only affect stateless, message-driven and stateful beans currently. Entity beans are not really pooled currently. Since stateful beans do not really have a pooled state, setting strictMaximumSize to true limits the number of instances that may be created rather than how many concurrent requests may be active. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=497673group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sar problems
On 2001.12.29 14:28:26 -0500 Dain Sundstrom wrote: I'm trying to convert my postgres-ds-service.xml file into a sar, so I don't have to copy the jar and then the service file. I created a sar file with my previous service file at META-INF/jboss-service.xml and the postgres jar (jdbc7.0-1.2.jar) in the root of the sar. Now when I copy the jar to the deploy directory, I get an exception about not being able to find the jdbc7.0-1.2.jar file. In my jboss-service.xml file I have the following xml: server classpath archives=jdbc7.0-1.2.jar/ /server Do I need to add something to the archives tag to tell it to look in the current sar? Since you are including the jar in the sar, you should remove the classpath element: it's there to help find stuff not in the sar. Anything in the sar should be picked up automatically. I there a way to integrate my sar into an ear? I haven't tried this yet: it may very well work, there is some code in j2ee deployer that is supposed to do this. Try just including the sar in the ear as if it is a ejb jar. Otherwise I presume when marc is done it will work. david jencks Thanks, -dain ___ 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] sar problems
Thanks that seamed to work. Now I am getting an exception RuntimeOperationException Object name cannot be null. Any ideas? -dain -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 2:13 PM To: Dain Sundstrom Cc: 'jboss-development @ lists . sourceforge . net' Subject: Re: [JBoss-dev] sar problems On 2001.12.29 14:28:26 -0500 Dain Sundstrom wrote: I'm trying to convert my postgres-ds-service.xml file into a sar, so I don't have to copy the jar and then the service file. I created a sar file with my previous service file at META-INF/jboss-service.xml and the postgres jar (jdbc7.0-1.2.jar) in the root of the sar. Now when I copy the jar to the deploy directory, I get an exception about not being able to find the jdbc7.0-1.2.jar file. In my jboss-service.xml file I have the following xml: server classpath archives=jdbc7.0-1.2.jar/ /server Do I need to add something to the archives tag to tell it to look in the current sar? Since you are including the jar in the sar, you should remove the classpath element: it's there to help find stuff not in the sar. Anything in the sar should be picked up automatically. I there a way to integrate my sar into an ear? I haven't tried this yet: it may very well work, there is some code in j2ee deployer that is supposed to do this. Try just including the sar in the ear as if it is a ejb jar. Otherwise I presume when marc is done it will work. david jencks Thanks, -dain ___ 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
[JBoss-dev] [ jboss-Change Notes-497678 ] UsernamePassword module hashing added
Change Notes item #497678, was opened at 2001-12-29 12:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=497678group_id=22866 Category: JBossSX Group: v2.4.4 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: UsernamePassword module hashing added Initial Comment: The base UsernamePasswordLoginModule now supports digest hashing of the input clear text password for comparsion in validatePassword(inputPassword, expectedPassword). The new options are: hashAlgorithm: The name of the MessageDigest algorithm to use to hash the password. This must be specified to enable hashing. hashEncoding: The string format for the hashed pass. It must be one of base64 or hex. Base64 is the default. hashCharset: The encoding used to convert the clear text password to a byte array. The platform default encoding is the default. When hashAlgorithm is specified, the clear text password obtained from the CallbackHandler is hashed before it is passed to validatePassword as the inputPassword argument. The expectedPassword as obtained via getUsersPassword() must be comparably hashed. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=497678group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sar problems
I'm trying to convert my postgres-ds-service.xml file into a sar, so I don't have to copy the jar and then the service file. I created a sar file with my previous service file at META-INF/jboss-service.xml and the postgres jar (jdbc7.0-1.2.jar) in the root of the sar. Now when I copy the jar to the deploy directory, I get an exception about not being able to find the jdbc7.0-1.2.jar file. In my jboss-service.xml file I have the following xml: server classpath archives=jdbc7.0-1.2.jar/ /server temporary The jar embedded in sar logic was a bit fucked up, I am about to commit the new stuff, greatly simplified and unified along with the unified classloader, it is so pretty and simple it makes me want to cry, anyway, saying in the version you are using, if you declare a classpath element it has to be outside the SAR, since you want the deployment done together (the classes and then the xml stuff mbean creation) you need to create a real sar, meaning a sar with the classes under / of the sar (unpacked). So think of the jar as the sar and in jar you just add the service.xml. In the near future (as soon as I commit) I do add support for anything included (done right, with external deployments) so you can pack your own sar with jars and not have to define anything. I am sorry to say that the explicit classpath dependency was a nightmare in code and usage introduced by David Jencks. I have gutted the code and streamlined the usage. let me know if the above doesn't make sense and be on the lookup for the new code it will support what you described. Do I need to add something to the archives tag to tell it to look in the current sar? Do the above, unpack your jar and repack it as a sar with the service.xml in META-INF. That should do the trick. I there a way to integrate my sar into an ear? In the code I will commit, you can include anything in anything, although the nested russian doll is a nightmare in packaging and why I am pushing away from it, but in any case I did add support for silliness as the one you describe above, i.e. pack anything in anything and if the sub-russian doll is recognized as a deployable type, it is first deployed as such (ear, sar, jar, war) and that is done recursively, so first all the inside dolls are deployed independently and then the outside doll is deployed, this is the way to define *implicitely*, though packaging, the dependencies of deployment. However *again* the recommend standardized way is to package your classes as a sar and be done with the russian doll crazyness. marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6402 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-497673 ] Support for strict EJB pooling added
Scott, *why* are you doing this. Really what is the point of limiting the number of concurrent accesses, please let us know, what is the use case and need? marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6404 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sar problems
On 2001.12.29 15:15:25 -0500 Dain Sundstrom wrote: Thanks that seamed to work. Now I am getting an exception RuntimeOperationException Object name cannot be null. Any ideas? -dain Have you switched your mbean-ref tags to depends and the associated name to optional-attribute-name? (I'm not convinced yet these are shorter, better, clearer, simpler names) If this isn't the problem can you post the jboss-service.xml? thanks david jencks -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 2:13 PM To: Dain Sundstrom Cc: 'jboss-development @ lists . sourceforge . net' Subject: Re: [JBoss-dev] sar problems On 2001.12.29 14:28:26 -0500 Dain Sundstrom wrote: I'm trying to convert my postgres-ds-service.xml file into a sar, so I don't have to copy the jar and then the service file. I created a sar file with my previous service file at META-INF/jboss-service.xml and the postgres jar (jdbc7.0-1.2.jar) in the root of the sar. Now when I copy the jar to the deploy directory, I get an exception about not being able to find the jdbc7.0-1.2.jar file. In my jboss-service.xml file I have the following xml: server classpath archives=jdbc7.0-1.2.jar/ /server Do I need to add something to the archives tag to tell it to look in the current sar? Since you are including the jar in the sar, you should remove the classpath element: it's there to help find stuff not in the sar. Anything in the sar should be picked up automatically. I there a way to integrate my sar into an ear? I haven't tried this yet: it may very well work, there is some code in j2ee deployer that is supposed to do this. Try just including the sar in the ear as if it is a ejb jar. Otherwise I presume when marc is done it will work. david jencks Thanks, -dain ___ 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] [ jboss-Change Notes-497673 ] Support for strict EJB pooling added
When the user is associating resources that are limited in quantity with a pooled instance. Right now the MaximumSize bound is really meaningless as you can have an unbounded number of instances active. This policy flag simply enforces the MaximumSize bound. The policy is not enabled by default so you won't notice it unless you change the container configuration. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 12:19 PM Subject: Re: [JBoss-dev] [ jboss-Change Notes-497673 ] Support for strict EJB pooling added Scott, *why* are you doing this. Really what is the point of limiting the number of concurrent accesses, please let us know, what is the use case and need? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Windows and installURL/codebase
Hi, There appears to be some funny code in the ServiceDeployer and Main that basically does if (urlString.startsWith(file:) !urlString.endsWith(File.separator)) urlString += File.separator; On windows you end up with foo/bar/\ which later confuses the service deployer when constructing the codebase for a SAR - double / file:/foo/bar//lib/ext/blah.jar And then the service deployer deploys it twice because they are different URLs. Which then leads to an IllegalAccessError. I've seen this for hsqldb.jar, I think Scott reported this last week? Is this code just wrong or is there some reason? If its a file: url all separators should be /. Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6407 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment ServiceDeployer.java
User: starksm
Date: 01/12/29 13:57:20
Modified:src/main/org/jboss/deployment ServiceDeployer.java
Log:
Fix the invalid file URL constructs that were using the platform
dependent path seperator rather than '/'.
Revision ChangesPath
1.21 +3 -3 jboss/src/main/org/jboss/deployment/ServiceDeployer.java
Index: ServiceDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/ServiceDeployer.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- ServiceDeployer.java 2001/12/20 06:11:12 1.20
+++ ServiceDeployer.java 2001/12/29 21:57:20 1.21
@@ -49,7 +49,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
-* @version $Revision: 1.20 $ p
+* @version $Revision: 1.21 $ p
*
* b20010830 marc fleury:/b
* ulinitial import
@@ -406,9 +406,9 @@
}
// Let's make sure the formatting of the codebase ends with the /
-if (codebase.startsWith(file:) !codebase.endsWith(File.separator))
+if (codebase.startsWith(file:) !codebase.endsWith(/))
{
- codebase += File.separator;
+ codebase += /;
}
else if (codebase.startsWith(http:) !codebase.endsWith(/))
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: starksm
Date: 01/12/29 13:57:20
Modified:src/main/org/jboss Main.java
Log:
Fix the invalid file URL constructs that were using the platform
dependent path seperator rather than '/'.
Revision ChangesPath
1.60 +3 -3 jboss/src/main/org/jboss/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- Main.java 2001/12/07 03:00:32 1.59
+++ Main.java 2001/12/29 21:57:20 1.60
@@ -46,7 +46,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
-* @version $Revision: 1.59 $
+* @version $Revision: 1.60 $
*
* bRevisions:/b
* p
@@ -275,8 +275,8 @@
String systemHome = System.getProperty(jboss.system.home);
String installURL = new File(systemHome).toURL().toString();
- if (!installURL.endsWith(File.separator)) {
- installURL += File.separator;
+ if (!installURL.endsWith(/)) {
+ installURL += /;
}
// Default configuration name is default,
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Windows and installURL/codebase
Thanks for pointing that out. This is just wrong and that is not the only
place where the handling of URLs is incorrect. The problem starts with the
setup of the installURL in Main:
String installURL = new File(systemHome).toURL().toString();
if (!installURL.endsWith(File.separator)) {
installURL += File.separator;
}
Which produces this bogus value:
2001-12-29 13:45:15,968 DEBUG [org.jboss.system.GPA]
jboss.system.installationURL:
file:/D:/usr/local/src/cvsroot/Main/jboss-all/build/output/jboss-3.0.0alpha/
\
This should be:
String installURL = new File(systemHome).toURL().toString();
if (!installURL.endsWith(/)) {
installURL += /;
}
Since as you say, URLs only use '/' as a path seperator. After correcting
both
of these I am able to run tests that make use of the hsqldb service on
Win2k.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Adrian Brock [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 29, 2001 1:00 PM
Subject: [JBoss-dev] Windows and installURL/codebase
Hi,
There appears to be some funny code in
the ServiceDeployer and Main that basically does
if (urlString.startsWith(file:) !urlString.endsWith(File.separator))
urlString += File.separator;
On windows you end up with
foo/bar/\
which later confuses the service deployer when
constructing the codebase for a SAR - double /
file:/foo/bar//lib/ext/blah.jar
And then the service deployer deploys it twice
because they are different URLs.
Which then leads to an IllegalAccessError.
I've seen this for hsqldb.jar, I think Scott
reported this last week?
Is this code just wrong or is there some reason?
If its a file: url all separators should be /.
Regards,
Adrian
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Windows and installURL/codebase
Hi Scott, Have you updated CVS? Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6407 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Windows and installURL/codebase
Ok, I see you have. Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6407 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Logging Analysis
Hi, I think I'm going to remove LogAnalysis. I'm getting an IllegalAccessError which is something to do with the code existing in jboss-spine.jar and jboss.jar. It was clearly a hack anyway! I'll give anybody who wants this analysis 24hrs notice to run it and save the results. I'll remove it Monday. Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6196 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
Hi,
There is a reason why I did not start the pool from the ContainerFactory
(well another that the classloader issue that you fixed ;) )
The setSessionContext have, in most cases, Home lookup (to cache them)
and if all beans are not deployed you can have JNDI lookup failure (when
using flat ejb-jar's for example). It is a problem that can happen in
other cases as well I must agree and that the developer should take care
of, but it appears as a Jboss bug when you first see it.
I can only see one solution : have a postinit() method in container that
is called when all containers have started.
Vincent.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Scott M Stark
Sent: vendredi 28 décembre 2001 23:35
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb/plugins
AbstractInstancePool.java
MessageDrivenInstanceInterceptor.java
StatefulSessionInstanceInterceptor.java
StatelessSessionInstanceInterceptor.java
User: starksm
Date: 01/12/28 14:35:14
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstancePool.java
MessageDrivenInstanceInterceptor.java
StatefulSessionInstanceInterceptor.java
StatelessSessionInstanceInterceptor.java
Log:
Add a strict pooling behavior that limits the number of
instances to that
specified by the container-pool-conf/MaximumSize
Revision ChangesPath
No revision
No revision
1.9.6.6 +138 -65
jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java
Index: AbstractInstancePool.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractIn
stancePool.java,v
retrieving revision 1.9.6.5
retrieving revision 1.9.6.6
diff -u -r1.9.6.5 -r1.9.6.6
--- AbstractInstancePool.java 2001/12/27 19:41:16 1.9.6.5
+++ AbstractInstancePool.java 2001/12/28 22:35:13 1.9.6.6
@@ -17,24 +17,26 @@
import org.jboss.ejb.EnterpriseContext;
import org.w3c.dom.Element;
+
+import EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore;
+
import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.XmlLoadable;
import org.jboss.logging.Logger;
/**
- * review
* Abstract Instance Pool class containing the basic logic
to create
* an EJB Instance Pool.
- * /review
*
* @see related
* @author a
href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a
href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
- * @author a
href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
+ * @author a
href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
+ * @author a
href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
+ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
*
- * @version $Revision: 1.9.6.5 $
+ * @version $Revision: 1.9.6.6 $
*
* pbRevisions:/b
* pb20010704 marcf:/b
@@ -56,19 +58,26 @@
// Constants
-
// Attributes
+ /** A semaphore that is set when the strict max size
behavior is in effect.
+When set, only maxSize instance may be active and any
attempt to get an
+instance will block until an instance is freed.
+*/
+ private FIFOSemaphore strictMaxSize;
+ /** The time in milliseconds to wait for the
strictMaxSize semaphore.
+*/
+ private long strictTimeout = Long.MAX_VALUE;
+ /** The logging interface */
protected Logger log = Logger.getLogger(this.getClass());
-
+ /** The Container the instance pool is associated with */
protected Container container;
-
/** The instance pool stack */
protected Stack pool = new Stack();
/** The maximum number of instances allowed in the pool */
protected int maxSize = 30;
/** determine if we reuse EnterpriseContext objects
i.e. if we actually do pooling */
protected boolean reclaim = false;
-
+ /** The pool seed task set from the feeder-policy
config element */
protected InstancePoolFeeder poolFeeder;
- protected boolean useFeeder = false;
// Static
@@ -103,14 +112,14 @@
public void start()
throws Exception
{
+ if( poolFeeder != null poolFeeder.isStarted() == false )
+ poolFeeder.start();
}
public void stop()
{
- if (useFeeder poolFeeder.isStarted())
- {
+ if( poolFeeder !=
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
Hi Scott; I will be trying out JBoss_2.4.4-Jetty_3.1.3-1_beta tonight. I must say that you and your [JBoss-dev] team (Especially Sacha Labourey, and Vincent Harcq) are very responsive, and helpful. If anything, I'm more sure today than yesterday that I'm investing my time, as well as our software's platform into the right (BEST) direction. Wishing you all much success, and Happy new year ;) Thanks Jeff. PS: Can't promise that this will be the last you hear from me ;) From: Scott M Stark [EMAIL PROTECTED] Reply-To: Scott M Stark [EMAIL PROTECTED] To: jeff andrews [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Date: Sat, 29 Dec 2001 12:10:06 -0800 Hi Scott; Thanks for your assistance. I'm wondring about two things: - When can I expect this feature inhavcement, and which version of JBoss should I look for it in? Now in 2.4.4, see https://sourceforge.net/tracker/index.php?func=detailaid=497673group_id=22 866atid=381174 - Also when testing the performance behaviour of stateful session beans type on JBoss, the performance was always the same with no defference, wither we had a cache min/max-capacity of 1, 10, 20, ..etc for 5 (for example) concurrent requesting clients. Shoudn't the performance behviuor improve as I increase the initial cache min/max-capacity value , in order to aviode the performance cost of client's request cache misses. Or is the same kind of behaviour is happenning as what is/was happenning with the bean pooling (above), for the case of concurrent requesting clients ? Would the same thing apply to Entity bean types to some degree too? Its probably the same lax implementation of the max bound, but this is a different pooling layer that I have not looked at for a while. Entity beans are not effectively pooled due to changes to generalize the locking policy, and are still not in 2.4.4. PS: For some reason I'm only able to get e-mails from [JBoss-dev] for those ones that explicitly include me in their To: address list. General [JBoss-dev] communications I'm not able to receive/see. That's why I missed your e-mail earlier. You don't have this email address subscribed to jboss-dev so there is no reason you should be getting posts. Check your subscription address or create one. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 221 Successful tests: 203 Errors:15 Failures: 3 [time of test: 30 December 2001 2:49 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/test JBossMQUnitTestCase.java
User: chirino
Date: 01/12/29 19:02:16
Modified:src/main/org/jboss/test/jbossmq/test
JBossMQUnitTestCase.java
Log:
Fixed a NPE
Revision ChangesPath
1.8 +6 -0
jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java
Index: JBossMQUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JBossMQUnitTestCase.java 2001/12/09 05:55:06 1.7
+++ JBossMQUnitTestCase.java 2001/12/30 03:02:16 1.8
@@ -384,6 +384,7 @@
public void testTopics() throws Exception {
getLog().debug(Starting Topic test);
+ connect();
TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.lookup(TOPIC_FACTORY);
topicConnection = topicFactory.createTopicConnection(john,needle);
@@ -443,6 +444,8 @@
topicConnection.stop();
topicConnection.close();
+
+ disconnect();
getLog().debug(Topic test passed);
}
/**
@@ -452,6 +455,7 @@
*/
public void testTopicNoLocal() throws Exception {
getLog().debug(Starting TopicNoLocal test);
+ connect();
TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.lookup(TOPIC_FACTORY);
TopicConnection topicConnection1 = topicFactory.createTopicConnection();
@@ -496,6 +500,8 @@
topicConnection1.close();
topicConnection2.stop();
topicConnection2.close();
+
+ disconnect();
getLog().debug(TopicNoLocal test passed);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 217 Successful tests: 203 Errors:11 Failures: 3 [time of test: 30 December 2001 3:35 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 217 Successful tests: 203 Errors:11 Failures: 3 [time of test: 30 December 2001 4:45 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 217 Successful tests: 203 Errors:11 Failures: 3 [time of test: 30 December 2001 5:42 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
Oh, well, that is what comments and test cases are for. Add a test case that demonstrates the problem and I'll fix this in the next release. Hi, There is a reason why I did not start the pool from the ContainerFactory (well another that the classloader issue that you fixed ;) ) The setSessionContext have, in most cases, Home lookup (to cache them) and if all beans are not deployed you can have JNDI lookup failure (when using flat ejb-jar's for example). It is a problem that can happen in other cases as well I must agree and that the developer should take care of, but it appears as a Jboss bug when you first see it. I can only see one solution : have a postinit() method in container that is called when all containers have started. Vincent. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 6:15 PM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
The beta does not have the change. It exists only in the final release of 2.4.4. - Original Message - From: jeff andrews [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 6:28 PM Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Hi Scott; I will be trying out JBoss_2.4.4-Jetty_3.1.3-1_beta tonight. I must say that you and your [JBoss-dev] team (Especially Sacha Labourey, and Vincent Harcq) are very responsive, and helpful. If anything, I'm more sure today than yesterday that I'm investing my time, as well as our software's platform into the right (BEST) direction. Wishing you all much success, and Happy new year ;) Thanks Jeff. PS: Can't promise that this will be the last you hear from me ;) From: Scott M Stark [EMAIL PROTECTED] Reply-To: Scott M Stark [EMAIL PROTECTED] To: jeff andrews [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Date: Sat, 29 Dec 2001 12:10:06 -0800 Hi Scott; Thanks for your assistance. I'm wondring about two things: - When can I expect this feature inhavcement, and which version of JBoss should I look for it in? Now in 2.4.4, see https://sourceforge.net/tracker/index.php?func=detailaid=497673group_id=2 2 866atid=381174 - Also when testing the performance behaviour of stateful session beans type on JBoss, the performance was always the same with no defference, wither we had a cache min/max-capacity of 1, 10, 20, ..etc for 5 (for example) concurrent requesting clients. Shoudn't the performance behviuor improve as I increase the initial cache min/max-capacity value , in order to aviode the performance cost of client's request cache misses. Or is the same kind of behaviour is happenning as what is/was happenning with the bean pooling (above), for the case of concurrent requesting clients ? Would the same thing apply to Entity bean types to some degree too? Its probably the same lax implementation of the max bound, but this is a different pooling layer that I have not looked at for a while. Entity beans are not effectively pooled due to changes to generalize the locking policy, and are still not in 2.4.4. PS: For some reason I'm only able to get e-mails from [JBoss-dev] for those ones that explicitly include me in their To: address list. General [JBoss-dev] communications I'm not able to receive/see. That's why I missed your e-mail earlier. You don't have this email address subscribed to jboss-dev so there is no reason you should be getting posts. Check your subscription address or create one. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ 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
