[JBoss-dev] CVS update: jboss/src/lib jbosscx.jar jbosscx-0.2.jar
User: starksm Date: 01/06/21 01:15:19 Added: src/lib Tag: Branch_2_4 jbosscx.jar Removed: src/lib Tag: Branch_2_4 jbosscx-0.2.jar Log: Merge JBossCX changes Revision ChangesPath No revision No revision 1.1.2.1 +193 -0jboss/src/lib/Attic/jbosscx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/pictures cvs_structure.png
User: starksm Date: 01/06/21 01:19:52 Modified:pictures cvs_structure.png Log: Add section on CHECKING IN A PATCH ON A NON-JBOSS CVS MODULE RELEASE BRANCH Fix some typos and clarify a bit Revision ChangesPath 1.4 +29 -20newsite/pictures/cvs_structure.png Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite CVSAdmin.jsp
User: starksm Date: 01/06/21 01:19:52 Modified:.CVSAdmin.jsp Log: Add section on CHECKING IN A PATCH ON A NON-JBOSS CVS MODULE RELEASE BRANCH Fix some typos and clarify a bit Revision ChangesPath 1.4 +97 -30newsite/CVSAdmin.jsp Index: CVSAdmin.jsp === RCS file: /cvsroot/jboss/newsite/CVSAdmin.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- CVSAdmin.jsp 2001/06/18 19:59:50 1.3 +++ CVSAdmin.jsp 2001/06/21 08:19:52 1.4 @@ -1,6 +1,6 @@ jsp:include page=head.jsp flush=true / jsp:include page=slogan.jsp flush=true - jsp:param name=SLOGAN value=JBoss CVS Administration Policy/ + jsp:param name=SLOGAN value=JBoss CVS Administration Policy/ /jsp:include @@ -66,46 +66,62 @@ li Prior to event 1, the latest alpha development build is Rel_2_1_0_57. At this point it is decided to create a new binary release. +/li li -Event 1 is the creation of a 2.2 branch. It is labeled with a branch tag of Branch_2_2. This fixes the +This is the creation of a 2.2 branch. It is labeled with a branch tag of Branch_2_2. This fixes the major version to 2 and the minor version to 2 for all tags on this branch. +/li li -Event 2 is the creation of a Rel_2_2_0_0 beta release tag in the branch. It serves as -an alias to the state of the main branch at the time the 2.2 branch was created. -li -Event 3 is the creation of a Rel_2_3_0_0 alpha release tag on the main trunk. It +This is the creation of a Rel_2_3_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.2 branch creation. +/li li -Event 4 is the integration of the first patch/change into the 2.2 branch. After +This is the creation of a Rel_2_2_0_0 beta release tag in the branch. It serves as +an alias to the state of the main branch at the time the 2.2 branch was created. +/li +li +This is the integration of the first patch/change into the 2.2 branch. After the code is commited the Rel_2_2_0_1 tag is applied. +/li li -Event 5 is the release of the initial 2.2 branch binary. The release is tagged +This is the release of the initial 2.2 branch binary. The release is tagged as JBoss_2_2_0 as well as Rel_2_2_1_0 to start the next beta series. +/li li -Event 6 is the integration of the first patch/change after the 2.2.0 binary +This is the integration of the first patch/change after the 2.2.0 binary release. After the code is commited the Rel_2_2_1_1 tag is applied. li -Event 7 is the release of the second 2.2 branch binary. The release is tagged +This is the release of the second 2.2 branch binary. The release is tagged as JBoss_2_2_1 as well as Rel_2_2_2_0 to start the next beta series. +/li +li +This is the release of a development binary. The release is tagged +as JBoss_2_3_1 as well as Rel_2_3_1_0 to start the next alpha series. +Prior to this there had also been a JBoss_2_3_0 development binary +not shown in the diagram. +/li li -Event 8 is the creation of a new binary release branch. After some period of -development on the 2.3 releases(Rel_2_3_0_0 to Rel_2_3_1_37), it is decided +This is the creation of a new binary release branch. After some period of +development on the 2.3 portion of the trunk(Rel_2_3_0_0 to Rel_2_3_1_37), it is decided to release a final binary incorporating the main trunk functionality. The new 2.4 branch is labeled with a branch tag of Branch_2_4. This fixes the major version to 2 and the minor version to 4 for all tags on this branch. +/li li -Event 9 is the creation of a Rel_2_4_0_0 beta release tag in the branch. It serves as -an alias to the state of the main branch at the time the 2.4 branch was created. -li -Event 10 is the creation of a Rel_2_5_0_0 alpha release tag on the main trunk. It +This is the creation of a Rel_2_5_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.4 branch creation. +/li +li +This is the creation of a Rel_2_4_0_0 beta release tag in the branch. It serves as +an alias to the state of the main branch at the time the 2.4 branch was created. +/li li -Event 11 is the integration of the first patch/change into the 2.4 branch. After +This is the integration of the first patch/change into the 2.4 branch. After the code is commited the Rel_2_4_0_1 tag is applied. li -Event 12 is the release of the initial 2.4 branch binary. The release is tagged +This is the release of the initial 2.4 branch binary. The release is tagged as JBoss_2_4_0 as well as Rel_2_4_1_0 to start the next beta series. /ol @@ -130,7 +146,7 @@ li(optional) Tag the code with the next alpha build tag. For example, to tag the jboss source tree
[JBoss-dev] CVS update: jbosscx/src/build build.xml
User: starksm
Date: 01/06/21 01:22:54
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Drop the version portion of the generated jbosscx.jar
Revision ChangesPath
No revision
No revision
1.4.2.1 +1 -1 jbosscx/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosscx/src/build/build.xml,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- build.xml 2001/04/30 11:09:18 1.4
+++ build.xml 2001/06/21 08:22:54 1.4.2.1
@@ -69,7 +69,7 @@
/copy--
mkdir dir=${external.dir}/
-jar jarfile=${external.dir}/${name}-${version}.jar
+jar jarfile=${external.dir}/${name}.jar
basedir=${build.classes.dir}
includes=org/jboss/resource/**
/
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/build build.xml
User: starksm
Date: 01/06/21 01:39:42
Modified:src/build build.xml
Log:
Drop the version number from the jbosscx.jar
Revision ChangesPath
1.5 +1 -1 jbosscx/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosscx/src/build/build.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.xml 2001/04/30 11:09:18 1.4
+++ build.xml 2001/06/21 08:39:42 1.5
@@ -69,7 +69,7 @@
/copy--
mkdir dir=${external.dir}/
-jar jarfile=${external.dir}/${name}-${version}.jar
+jar jarfile=${external.dir}/${name}.jar
basedir=${build.classes.dir}
includes=org/jboss/resource/**
/
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/build build.xml
User: starksm
Date: 01/06/21 07:54:03
Modified:tomcat/src/build build.xml
Log:
Don't export JBOSS_CLASSPATH until it is defined in run_with_tomcat.sh
Revision ChangesPath
1.15 +3 -2 contrib/tomcat/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- build.xml 2001/06/10 03:20:54 1.14
+++ build.xml 2001/06/21 14:54:03 1.15
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=UTF-8 ?
-!-- $Id: build.xml,v 1.14 2001/06/10 03:20:54 starksm Exp $ --
+!-- $Id: build.xml,v 1.15 2001/06/21 14:54:03 starksm Exp $ --
!-- An Ant build file for the tomcat-service jar and the
JBoss/Tomcat bundle. The buildfile requires a JBoss dist
@@ -144,7 +144,8 @@
patch patchfile=${etc.dir}/conf/tomcat/server.xml.patch
originalfile=${bundle.root}/tomcat/conf/server.xml /
echo file=${bundle.root}/jboss/bin/run_with_tomcat.sh#!/bin/sh
-export JBOSS_CLASSPATH=$$JBOSS_CLASSPATH:$$JAVA_HOME/lib/tools.jar
+JBOSS_CLASSPATH=$$JBOSS_CLASSPATH:$$JAVA_HOME/lib/tools.jar
+export JBOSS_CLASSPATH
/bin/sh ./run.sh tomcat
/echo
echo file=${bundle.root}/jboss/bin/run_with_tomcat.bat@echo off
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jboss-docs] JDBC - Hypersonic
Using
hypersonicwith trace on,I did
noticetherethe exception: "java.sql.SQLException: Connection closed"
everytime thea tablewas created or attemptedto be
created.This was occuring when con.close() was being
executed from org.jboss.ejb.plugins.jaws.jdbc on line 110. For some
reason, the SQLException being thrown by the XAClientConnection object was not
being caught in the catch statement.Replacing line 110 with
try
{ if (!con.isClosed())
if(con != null) try {con.close(); con = null;}catch(SQLException e)
{} }catch (Exception e)
{}
fixed this problem. Is
this exception you weregetting?
By updating
configuration settings do you mean mentioning how you would connect to a version
1.6 databasealso?
David
Nordahl
[EMAIL PROTECTED]
-Original
Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Tobias FrechSent: Wednesday, June 20, 2001 12:07
PMTo: [EMAIL PROTECTED]Cc:
[EMAIL PROTECTED]Subject: Re: [jboss-docs] Guidelines for compliance and
database testing
Hi David!JBoss comes with
Hypersonic preconfigured. But there is a Hypersonicentry in the manual
anyway. The dbtest basically works (for me). But Isaw that the server
threw several Exceptions while testing. You couldinvestigate further if we
do have to worry about these Exceptions on theserver. Finally an update of
the configuration setting in the manualwould be good.For further
guidelines see:http://groups.yahoo.com/group/jboss-docs/files/compliance-tasks.txtCheers,Tobias"Nordahl, David C"
wrote: Hi everybody, I would very much like to work
on the compliance check for the Hypersonic JDBC section. David
Nordahl [EMAIL PROTECTED]
[JBoss-dev] CVS update: newsite CVSAdmin.jsp
User: starksm Date: 01/06/21 12:23:33 Modified:.CVSAdmin.jsp Log: Use even_minor/odd_minor to distinguish the branch/main labels Revision ChangesPath 1.5 +2 -2 newsite/CVSAdmin.jsp Index: CVSAdmin.jsp === RCS file: /cvsroot/jboss/newsite/CVSAdmin.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- CVSAdmin.jsp 2001/06/21 08:19:52 1.4 +++ CVSAdmin.jsp 2001/06/21 19:23:33 1.5 @@ -168,7 +168,7 @@ cvs tag Rel_2_3_0_0 /pre li -Create the new branch giving it a branch tag of Branch_lt;majorgt;_lt;minorgt;. For +Create the new branch giving it a branch tag of Branch_lt;majorgt;_lt;even_minorgt;. For example, to create a 2.2 branch, perform the following within the working directory created by the previous check out: pre @@ -182,7 +182,7 @@ /pre li Label the branch working directory with the initial beta release tag of -Rel_lt;majorgt;_lt;minorgt;_0_0. For the Branch_2_2 case this would be +Rel_lt;majorgt;_lt;even_minorgt;_0_0. For the Branch_2_2 case this would be done by executing the following in the working directory created by the previous check out: pre ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TinderBox...
Hi, I am sort of doing something towards this now. The site http://lubega.com is produced by an automated daily script that does a cvs update and then a rebuild and test of the jboss/jbosstest code. It only covers 1 platform/JVM - 386Linux2.2, Sun JVM 1.3. I could fairly easily add alternate builds with different linux jvms. I guess the real work is in ensuring the tests provide good coverage and ensuring they work consistently - the current jmsra ones seem to switch between failing and working at random... And then there is setting up a tinderbox server... What kind of bandwidth requirements do you see being needed? Can tinderbox work off a daily rebuild or does it need to happen realtime as code is checked in? Although I guess intraday updates of the tree should not eat much bandwidth... Chris PS http://www.mozilla.org/tinderbox.html I must read more about tinderbox... = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TinderBox...
Nice ! Yeah, Chris - that's something like what I'm talking about - here is how I understand it works. A number of clients are set up with different build environments and/or build targets, or even versions e.g. MAIN and 2.4 and 3.0 They run a script that loops infinitely with a pause (0-???) between builds. They check out or refresh a tree from the Tinderbox/CVS (I'm not sure if this has to be the same host - but I suspect so) server, mail the tinderbox server saying who they are and what they intend to do etc... They do a build then mail the server the results. The server builds a nice results page with a table of platforms against time. http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports in a realtime situation you can get pretty swift feedback as to whether you have broken anything on any platform. The idea is that after checking in code you make yourself available until you can see that all builds are green, then you are free to go to bed. Anyone wanting to check out a working tree can just look back up the timeline for the last successful build and check it out. If a build is broken, tinderbox tries to figure out which file broke and who was responsible. Peer pressure should soon put a stop to people breaking the build ! I think simply having someone checking your changes out, building them and letting you know if they worked on another machine is pretty reassuring in itself. I'll keep the list informed of my findings. We should probably talk some more soon if you are interested. It shouldn't be hard to find lots of people to volunteer to be tinderbox clients, but the tinderbox server might be a bit trickier. My main concern at the moment is that tinderbox expects direct access to the CVS repository, and that is on SourceForge, so we may have to mirror it Thanks for your interest, Jules Chris Kimpton wrote: Hi, I am sort of doing something towards this now. The site http://lubega.com is produced by an automated daily script that does a cvs update and then a rebuild and test of the jboss/jbosstest code. It only covers 1 platform/JVM - 386Linux2.2, Sun JVM 1.3. I could fairly easily add alternate builds with different linux jvms. I guess the real work is in ensuring the tests provide good coverage and ensuring they work consistently - the current jmsra ones seem to switch between failing and working at random... And then there is setting up a tinderbox server... What kind of bandwidth requirements do you see being needed? Can tinderbox work off a daily rebuild or does it need to happen realtime as code is checked in? Although I guess intraday updates of the tree should not eat much bandwidth... Chris PS http://www.mozilla.org/tinderbox.html I must read more about tinderbox... = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjaws.xml
User: patriot1burke Date: 01/06/21 14:50:37 Modified:src/etc/conf/default standardjaws.xml Log: read-ahead flag is now defaultable in standardjaws.xml Revision ChangesPath 1.17 +1 -0 jboss/src/etc/conf/default/standardjaws.xml Index: standardjaws.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjaws.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- standardjaws.xml 2001/06/19 07:38:21 1.16 +++ standardjaws.xml 2001/06/21 21:50:36 1.17 @@ -11,6 +11,7 @@ read-onlyfalse/read-only time-out300/time-out select-for-updatefalse/select-for-update + read-aheadfalse/read-ahead /default-entity type-mappings ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosscx.jar jbosscx-0.2.jar
User: user57 Date: 01/06/21 14:51:51 Added: src/lib jbosscx.jar Removed: src/lib jbosscx-0.2.jar Log: o merged jbosscx.jar from Rel_2_4_0_1 removed jbosscx-0.2.jar too the main branch consistent. Revision ChangesPath 1.2 +193 -0jboss/src/lib/jbosscx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata FinderMetaData.java
User: patriot1burke
Date: 01/06/21 14:52:39
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
FinderMetaData.java
Log:
added setReadAhead method
Revision ChangesPath
1.4 +33 -23
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java
Index: FinderMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FinderMetaData.java 2001/05/27 00:49:16 1.3
+++ FinderMetaData.java 2001/06/21 21:52:38 1.4
@@ -20,22 +20,27 @@
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
* @author a href=[EMAIL PROTECTED]danch/a
- * @version $Revision: 1.3 $
+ * @author a href=[EMAIL PROTECTED]Bill Burke/a
+ * @version $Revision: 1.4 $
+ *
+ * Revisions:
+ * 20010621 Bill Burke: setReadAhead added.
+ *
*/
public class FinderMetaData extends MetaData implements XmlLoadable {
- // Constants -
+ // Constants -
- // Attributes
+ // Attributes
private String name;
- private String order;
- private String query;
+ private String order;
+ private String query;
/** do we perform 'read-ahead' of column values? (avoid making n+1 database
hits) */
private boolean readAhead = false;
- // Static
+ // Static
- // Constructors --
+ // Constructors --
/** default constructor */
public FinderMetaData() {
}
@@ -46,31 +51,36 @@
this.name = name;
}
- // Public
+ // Public
public String getName() { return name; }
- public String getOrder() { return order; }
+ public String getOrder() { return order; }
- public String getQuery() { return query; }
+ public String getQuery() { return query; }
public boolean hasReadAhead() { return readAhead; }
+
+ public void setReadAhead(boolean newval)
+ {
+ readAhead = newval;
+ }
- // XmlLoadable implementation
-public void importXml(Element element) throws DeploymentException {
- name = getElementContent(getUniqueChild(element, name));
- query = getElementContent(getUniqueChild(element, query));
- order = getElementContent(getUniqueChild(element, order));
+ // XmlLoadable implementation
+ public void importXml(Element element) throws DeploymentException {
+ name = getElementContent(getUniqueChild(element, name));
+ query = getElementContent(getUniqueChild(element, query));
+ order = getElementContent(getUniqueChild(element, order));
- // read ahead? If not provided, keep default.
- String readAheadStr = getElementContent(getOptionalChild(element,
read-ahead));
- if (readAheadStr != null) readAhead =
Boolean.valueOf(readAheadStr).booleanValue();
- }
+ // read ahead? If not provided, keep default.
+ String readAheadStr = getElementContent(getOptionalChild(element,
read-ahead));
+ if (readAheadStr != null) readAhead =
Boolean.valueOf(readAheadStr).booleanValue();
+ }
- // Package protected -
+ // Package protected -
- // Protected -
+ // Protected -
- // Private ---
+ // Private ---
- // Inner classes -
+ // Inner classes -
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata JawsEntityMetaData.java
User: patriot1burke
Date: 01/06/21 14:52:19
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
read-head is now defaultable in standardjboss.xml and jaws.xml
Revision ChangesPath
1.10 +221 -206
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JawsEntityMetaData.java 2001/06/06 01:07:40 1.9
+++ JawsEntityMetaData.java 2001/06/21 21:52:19 1.10
@@ -33,284 +33,299 @@
*
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.9 $
+ * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
+ * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
+ * @version $Revision: 1.10 $
+ *
+ * Revisions:
+ * 20010621 Bill Burke: made read-ahead defaultable in standardjboss.xml and
jaws.xml
*/
public class JawsEntityMetaData extends MetaData implements XmlLoadable {
- // Constants -
+ // Constants -
- // Attributes
+ // Attributes
- // parent metadata structures
- private JawsApplicationMetaData jawsApplication;
- private EntityMetaData entity;
+ // parent metadata structures
+ private JawsApplicationMetaData jawsApplication;
+ private EntityMetaData entity;
- // the name of the bean (same as entity.getEjbName())
- private String ejbName = null;
+ // the name of the bean (same as entity.getEjbName())
+ private String ejbName = null;
- // the name of the table to use for this bean
- private String tableName = null;
+ // the name of the table to use for this bean
+ private String tableName = null;
- // do we have to try and create the table on deployment?
- private boolean createTable;
+ // do we have to try and create the table on deployment?
+ private boolean createTable;
- // do we have to drop the table on undeployment?
- private boolean removeTable;
+ // do we have to drop the table on undeployment?
+ private boolean removeTable;
- // do we use tuned updates?
- private boolean tunedUpdates;
+ // do we use tuned updates?
+ private boolean tunedUpdates;
// do we use 'SELECT ... FOR UPDATE' syntax?
private boolean selectForUpdate;
- // is the bean read-only?
- private boolean readOnly;
- private int timeOut;
+ // is the bean read-only?
+ private boolean readOnly;
- // should the table have a primary key constraint?
- private boolean pkConstraint;
+ // make finders by default read-ahead?
+ private boolean readAhead;
+
+ private int timeOut;
+
+ // should the table have a primary key constraint?
+ private boolean pkConstraint;
- // is the bean's primary key a composite object
- private boolean compositeKey;
+ // is the bean's primary key a composite object
+ private boolean compositeKey;
- // the class of the primary key
- private Class primaryKeyClass;
+ // the class of the primary key
+ private Class primaryKeyClass;
- // the fields we must persist for this bean
- private Hashtable cmpFields = new Hashtable();
+ // the fields we must persist for this bean
+ private Hashtable cmpFields = new Hashtable();
- // the fields that belong to the primary key (if composite)
- private ArrayList pkFields = new ArrayList();
+ // the fields that belong to the primary key (if composite)
+ private ArrayList pkFields = new ArrayList();
- // finders for this bean
- private ArrayList finders = new ArrayList();
+ // finders for this bean
+ private ArrayList finders = new ArrayList();
- /**
- * Here we store the basename of all detailed fields in jaws.xml
- * (e.g., data for data.categoryPK).
- */
- private HashMap detailedFieldDescriptions = new HashMap();
+ /**
+* Here we store the basename of all detailed fields in jaws.xml
+* (e.g., data for data.categoryPK).
+*/
+ private HashMap detailedFieldDescriptions = new HashMap();
- /**
- * This is the Boolean we store as value in detailedFieldDescriptions
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
User: patriot1burke
Date: 01/06/21 14:51:47
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
removed loadEntities call from findEntities method. loadEntities is now obsolete.
Revision ChangesPath
1.23 +399 -395 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- CMPPersistenceManager.java2001/06/18 20:01:23 1.22
+++ CMPPersistenceManager.java2001/06/21 21:51:47 1.23
@@ -47,275 +47,279 @@
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
-* @version $Revision: 1.22 $
+* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
+* @version $Revision: 1.23 $
+*
+* Revisions:
+* 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
+* done directly by the finder.
+*
*/
public class CMPPersistenceManager
-implements EntityPersistenceManager {
-// Constants -
+ implements EntityPersistenceManager {
+ // Constants -
-// Attributes
-EntityContainer con;
-// Physical persistence implementation
-EntityPersistenceStore store;
-
-// The EJB Methods, the reason for this class
-Method ejbLoad;
-Method ejbStore;
-Method ejbActivate;
-Method ejbPassivate;
-Method ejbRemove;
+ // Attributes
+ EntityContainer con;
+ // Physical persistence implementation
+ EntityPersistenceStore store;
+
+ // The EJB Methods, the reason for this class
+ Method ejbLoad;
+ Method ejbStore;
+ Method ejbActivate;
+ Method ejbPassivate;
+ Method ejbRemove;
-HashMap createMethods = new HashMap();
-HashMap postCreateMethods = new HashMap();
+ HashMap createMethods = new HashMap();
+ HashMap postCreateMethods = new HashMap();
-// Static
+ // Static
// Constructors --
// Public
-public void setContainer(Container c) {
-con = (EntityContainer)c;
-if (store != null) store.setContainer(c);
-}
+ public void setContainer(Container c) {
+ con = (EntityContainer)c;
+ if (store != null) store.setContainer(c);
+ }
+
+
+ public void setPersistenceStore(EntityPersistenceStore store) {
+ this.store= store;
+
+ //Give it the container
+ if (con!= null) store.setContainer(con);
+ }
+
+ public void init()
+ throws Exception {
+
+ // The common EJB methods
+ ejbLoad = EntityBean.class.getMethod(ejbLoad, new Class[0]);
+ ejbStore = EntityBean.class.getMethod(ejbStore, new Class[0]);
+ ejbActivate = EntityBean.class.getMethod(ejbActivate, new Class[0]);
+ ejbPassivate = EntityBean.class.getMethod(ejbPassivate, new Class[0]);
+ ejbRemove = EntityBean.class.getMethod(ejbRemove, new Class[0]);
-
-public void setPersistenceStore(EntityPersistenceStore store) {
-this.store= store;
-
-//Give it the container
-if (con!= null) store.setContainer(con);
-}
-
-public void init()
-throws Exception {
-
-// The common EJB methods
-ejbLoad = EntityBean.class.getMethod(ejbLoad, new Class[0]);
-ejbStore = EntityBean.class.getMethod(ejbStore, new Class[0]);
-ejbActivate = EntityBean.class.getMethod(ejbActivate, new Class[0]);
-ejbPassivate = EntityBean.class.getMethod(ejbPassivate, new Class[0]);
-ejbRemove = EntityBean.class.getMethod(ejbRemove, new Class[0]);
-
- if (con.getHomeClass() != null)
- {
-Method[] methods = con.getHomeClass().getMethods();
-createMethodCache( methods );
- }
- if (con.getLocalHomeClass() != null)
- {
-Method[] methods = con.getLocalHomeClass().getMethods();
-createMethodCache( methods );
- }
+ if (con.getHomeClass() != null)
+ {
+ Method[] methods = con.getHomeClass().getMethods();
+ createMethodCache( methods );
+ }
+ if (con.getLocalHomeClass() != null)
+ {
+ Method
Re: [JBoss-dev] Fixed very small problem with ConnectionFactoryLoader
Thanks, I was really not sure what was needed to get this together. It looks like the main jboss branch did not get the latest unversioned jbosscx.jar, so I took the liberty to fix that. Thanks for updating the documentation too. --jason On Thu, 21 Jun 2001, Scott M Stark wrote: I updated the cvs admin doc to describe the steps for making a change in a non-jboss module and incorporating the module jars into the jboss release branch. I went through them for the jbosscx changes and this is what was done: Make a 2.4 branch for the jbosscx module: 1. cvs co jbosscx 2. cd jbosscx 3. cvs tag Rel_2_5_0_0 4. cvs tag -b Branch_2_4 5. cvs update -r Branch_2_4 6. cvs tag Rel_2_4_0_0 7. Make the required changes. All code changes had been made but the version portion of the jbosscx.jar needed to be removed so I did that. 8. Commit the changes 9. Tag the jbosscx 2.4 branch with the next beta release tag in the jboss module(not the jbosscx module). This happens to be Rel_2_4_0_1. From within the root jbosscx working directory: cvs tag Rel_2_4_0_1 10. Built the jbosscx.jar 11. Copied the jbosscx.jar into the jboss/src/lib directory 12. Removed the old jbosscx-0.2.jar 13. Added the new jbosscx.jar 14. Committed the changes 15. Tag the jboss module with Rel_2_4_0_1. From within the root jboss working directory: cvs tag Rel_2_4_0_1 16. Merge the change to build.xml made on the 2.4 branch to main. From within a working directory created by cvs co jbosscx: bash-2.04$ cvs update -j Rel_2_4_0_1 cvs server: Updating . RCS file: /cvsroot/jboss/jbosscx/src/build/build.xml,v retrieving revision 1.4 retrieving revision 1.4.2.1 Merging differences between 1.4 and 1.4.2.1 into build.xml ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFindEntityCommand.java
User: patriot1burke
Date: 01/06/21 14:56:28
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCFindEntityCommand.java
Log:
findByPrimaryKey may now do a read-ahead depending on configuration
Revision ChangesPath
1.7 +35 -18
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntityCommand.java
Index: JDBCFindEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntityCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCFindEntityCommand.java2001/05/27 00:49:15 1.6
+++ JDBCFindEntityCommand.java2001/06/21 21:56:28 1.7
@@ -20,6 +20,7 @@
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.plugins.jaws.JPMFindEntityCommand;
import org.jboss.ejb.plugins.jaws.JPMFindEntitiesCommand;
+import org.jboss.util.FinderResults;
/**
* JAWSPersistenceManager JDBCFindEntityCommand
@@ -29,20 +30,32 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.6 $
+ * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
+ * @version $Revision: 1.7 $
+ *
+ * Revision:
+ * 20010621 Bill Burke: findByPrimaryKey may now do a read-ahead depending on
configuration
*/
public class JDBCFindEntityCommand implements JPMFindEntityCommand
{
// Attributes
- JDBCBeanExistsCommand beanExistsCommand;
+ JDBCBeanExistsCommand beanExistsCommand = null;
+JDBCPreloadByPrimaryKeyCommand preloadByPrimaryKey = null;
JPMFindEntitiesCommand findEntitiesCommand;
// Constructors --
public JDBCFindEntityCommand(JDBCCommandFactory factory)
{
- beanExistsCommand = factory.createBeanExistsCommand();
+ if (factory.getMetaData().hasReadAhead())
+ {
+preloadByPrimaryKey = new JDBCPreloadByPrimaryKeyCommand(factory);
+ }
+ else
+ {
+beanExistsCommand = factory.createBeanExistsCommand();
+ }
findEntitiesCommand = factory.createFindEntitiesCommand();
}
@@ -55,8 +68,25 @@
{
if (finderMethod.getName().equals(findByPrimaryKey))
{
-
- return findByPrimaryKey(args[0]);
+ Object id = args[0];
+ if (preloadByPrimaryKey != null)
+ {
+ FinderResults result = preloadByPrimaryKey.execute(finderMethod, args,
ctx);
+ if (result.size() == 0)
+ {
+ throw new ObjectNotFoundException(No such entity!);
+ }
+ return id;
+ }
+ else if (beanExistsCommand.execute(id))
+ {
+ return id;
+ }
+ else
+ {
+ throw new ObjectNotFoundException(Object with primary key + id +
+ not found in storage);
+ }
}
else
{
@@ -77,17 +107,4 @@
}
}
- // Protected -
-
- protected Object findByPrimaryKey(Object id) throws FinderException
- {
- if (beanExistsCommand.execute(id))
- {
- return id;
- } else
- {
- throw new ObjectNotFoundException(Object with primary key + id +
-not found in storage);
- }
- }
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntityCommand.java
User: patriot1burke
Date: 01/06/21 14:57:52
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCLoadEntityCommand.java
Log:
added some debug messaging when debug flag is on.
Revision ChangesPath
1.13 +6 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
Index: JDBCLoadEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JDBCLoadEntityCommand.java2001/06/18 20:01:24 1.12
+++ JDBCLoadEntityCommand.java2001/06/21 21:57:52 1.13
@@ -39,7 +39,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*/
public class JDBCLoadEntityCommand
extends JDBCQueryCommand
@@ -143,6 +143,10 @@
Object[] data = factory.getPreloadData(ctx.getId());
if (data != null) {
loadFromPreload(data, ctx);
+ if (debug)
+ {
+ log.debug(preloading: + ctx.getId().toString());
+ }
} else {
jdbcExecute(ctx);
}
@@ -150,7 +154,7 @@
{
throw new ServerException(Load failed, e);
}
- }
+ }
}
// JDBCQueryCommand overrides
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCPreloadByPrimaryKeyCommand.java
User: patriot1burke
Date: 01/06/21 14:58:41
Added: src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCPreloadByPrimaryKeyCommand.java
Log:
read-ahead functionality when doing findByPrimaryKey
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCPreloadByPrimaryKeyCommand.java
Index: JDBCPreloadByPrimaryKeyCommand.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.jaws.jdbc;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import org.jboss.ejb.EntityEnterpriseContext;
/**
* JDBCPreloadByPrimaryKey
*
* This finder be called on when read-ahead is turned on and findByPrimaryKey
* is called. It will read-ahead instead of just the old exists logic.
*
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
* @version $Revision: 1.1 $
*/
public class JDBCPreloadByPrimaryKeyCommand extends JDBCPreloadFinderCommand
{
// Constructors --
public JDBCPreloadByPrimaryKeyCommand(JDBCCommandFactory factory)
{
super(factory, PreloadByPrimaryKey);
String sql = loadCommand.createSelectClause() + FROM +
jawsEntity.getTableName() +
WHERE + getPkColumnWhereList();
setSQL(sql);
}
// Public
// JDBCQueryCommand overrides
protected void setParameters(PreparedStatement stmt, Object argOrArgs)
throws Exception
{
Object[] objects = (Object[])argOrArgs;
setPrimaryKeyParameters(stmt, 1, objects[0]);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problem with jaws.xml
Andy the type-mappings will be in the standardjaws.xml file that Vincent updated. The deployer reads this first and likely isn't finding the PostgreSQL mapping because of the element name change. Probably a mismatch between the code changes in the metadata package and the element names in the standardjaws.xml. I think this will be reverted soon as per mails betwixt Scott and Vincent. Meantime check the version of the metadata classes and standardjaws.xml - if they are the updated ones that Vincent committed try checking out the previous versions instead and see if that fixes it. BTW which branch are you working on. I believe the updates have only been made on MAIN so far. Mike S-R At 10:31 21/06/2001 -0700, you wrote: Just as information the jaws.dtd looks like this: ?xml version=1.0 encoding=UTF-8? jaws datasourcejava:/PostgresDS/datasource type-mappingPostgreSQL/type-mapping enterprise-beans entity ejb-namejboss/survey/Survey/ejb-name table-nameSurvey/table-name create-tabletrue/create-table remove-tabletrue/remove-table cmp-field field-nameid/field-name column-nameId/column-name /cmp-field cmp-field field-namefirstName/field-name column-nameFirstName/column-name /cmp-field cmp-field field-namelastName/field-name column-nameLastName/column-name /cmp-field cmp-field field-namecompany/field-name column-nameCompany/column-name /cmp-field cmp-field field-nameemail/field-name column-nameEmail/column-name /cmp-field cmp-field field-namewebsite/field-name column-nameWebsite/column-name /cmp-field cmp-field field-namepermission/field-name column-namePermission/column-name /cmp-field cmp-field field-namejbossVersion/field-name column-nameJbossVersion/column-name /cmp-field cmp-field field-namejbossDownloadType/field-name column-nameJbossDownloadType/column-name /cmp-field cmp-field field-namejbossUsage/field-name column-nameJbossUsage/column-name /cmp-field cmp-field field-namejbossReason/field-name column-nameJbossReason/column-name /cmp-field cmp-field field-nameenvironmentEquipement/field-name column-nameEnvironmentEquipement/column-name /cmp-field cmp-field field-nameenvironmentOS/field-name column-nameEnvironmentOS/column-name /cmp-field cmp-field field-nameenvironmentProcessors/field-name column-nameEnvironmentProcessors/column-name /cmp-field cmp-field field-nameenvironmentRequests/field-name column-nameEnvironmentRequests/column-name /cmp-field cmp-field field-nameenvironmentDataSize/field-name column-nameEnvironmentDataSize/column-name /cmp-field cmp-field field-nameenvironmentStatelessEJBs/field-name column-nameEnvironmentStatelessEJBs/column-name /cmp-field cmp-field field-nameenvironmentStatefulEJBs/field-name column-nameEnvironmentStatefulEJBs/column-name /cmp-field cmp-field field-nameenvironmentEntityEJBs/field-name column-nameEnvironmentEntityEJBs/column-name /cmp-field cmp-field field-nameenvironmentMessageEJBs/field-name column-nameEnvironmentMessageEJBs/column-name /cmp-field cmp-field field-namejbossFeatures/field-name column-nameJbossFeatures/column-name /cmp-field cmp-field field-nameownInterceptors/field-name column-nameOwnInterceptors/column-name /cmp-field cmp-field field-nameownContainerInvokers/field-name column-nameOwnContainerInvokers/column-name /cmp-field cmp-field field-nameownMBeans/field-name column-nameOwnMBeans/column-name /cmp-field cmp-field field-nameownComments/field-name column-nameOwnComments/column-name /cmp-field cmp-field field-namecreationDate/field-name column-namecreation_date/column-name /cmp-field cmp-field field-namemodificationDate/field-name column-namemodification_date/column-name /cmp-field /entity /enterprise-beans /jaws As you see there is no
[JBoss-dev] [ jboss-Change Notes-435246 ] read-ahead expanded
Change Notes item #435246, was updated on 2001-06-21 15:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435246group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: read-ahead expanded Initial Comment: read-ahead feature of CMP/JAWS has now been extended New features: * the read-ahead flag is defaultable in standardjaws.xml and jaws.xml * The finder SQL select call and the LoadEntities SQL select call are now combined. Instead of 2 sql calls they are now one. * read-ahead is now extended to Single Entity finders and findByPrimaryKey. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435246group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] minerva / tm problems under load ?
Hello all, We have been stress testing jboss this past week and have found stability problems under load. Perhaps this is simply a configuration problem (I hope). The system setup : jboss-2.2.2, DB2 UDB w/ app version of jdbc 2.0 driver, redhat 6.2 on Intel, sun jdk 1.3.0 The test app : single BMP Entity bean with Required transaction attribute Under low load, the application runs perfectly. As load increases the exception A (shown at end) occurs about every 5 - 10 minutes. The root problem is being obscured by the ConcurrentModificationException. Looking at the minerva code in ObjectPool, there are 4 places where an iterator is used with insufficient protection from another thread modifying the underlying HashMap (field name : objects). I hacked ObjectPool in each case so a ConcurrentModificationException will restart the iteration. This allows exposing the real exception which is causing the transaction failure. That exception is shown as exception B. At this point I do not understand enough yet about minerva and the TxCapsule to know what causes the null XaRes exception, but I should point out that this exception occurs less than 1% of the time the business method is invoked, and only under load. After the first occurance of exception B, other transaction related exceptions start to appear (XAER_PROTO and XAER_NOTA). The worst part is that the database connection is forgotten, neither rolled back nor commited nor ever used again. Does anyone have a suggestion how to begin debugging this? Thanks alot for any suggestions, Wayne Exception A (stock minerva in jboss-2.2.2) [Mailbox] CONTAINER EXCEPTION:null [Mailbox] java.util.ConcurrentModificationException [Mailbox] at java.util.HashMap$HashIterator.next(HashMap.java:736) [Mailbox] at java.util.AbstractCollection.addAll(AbstractCollection.java:317) [Mailbox] at java.util.HashSet.init(HashSet.java:86) [Mailbox] at org.opentools.minerva.pool.ObjectPool.getUsedCount(ObjectPool.java:693) [Mailbox] at org.opentools.minerva.pool.ObjectPool.toString(ObjectPool.java:705) [Mailbox] at java.lang.String.valueOf(String.java:1925) [Mailbox] at java.lang.StringBuffer.append(StringBuffer.java:373) [Mailbox] at org.opentools.minerva.pool.ObjectPool.releaseObject(ObjectPool.java:680) [Mailbox] at org.opentools.minerva.jdbc.xa.XAConnectionFactory$3.transactionFailed(XAConn ectionFactory.j ava:153) [Mailbox] at org.opentools.minerva.jdbc.xa.wrapper.XAConnectionImpl.transactionFailed(XAC onnectionImpl.j ava:150) [Mailbox] at org.opentools.minerva.jdbc.xa.wrapper.XAResourceImpl.forget(XAResourceImpl.j ava:142) [Mailbox] at org.jboss.tm.TxCapsule.gotHeuristic(TxCapsule.java:1310) [Mailbox] at org.jboss.tm.TxCapsule.prepareResources(TxCapsule.java:1450) [Mailbox] at org.jboss.tm.TxCapsule.commit(TxCapsule.java:347) [Mailbox] at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) [Mailbox] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:318) [Mailbox] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99) [Mailbox] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:19 0) [Mailbox] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195) [Mailbox] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323) [Mailbox] at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI nvoker.java:392 ) [Mailbox] at java.lang.reflect.Method.invoke(Native Method) [Mailbox] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) [Mailbox] at sun.rmi.transport.Transport$1.run(Transport.java:142) [Mailbox] at java.security.AccessController.doPrivileged(Native Method) [Mailbox] at sun.rmi.transport.Transport.serviceCall(Transport.java:139) [Mailbox] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443) [Mailbox] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:6 43) [Mailbox] at java.lang.Thread.run(Thread.java:484) Exception B (patched minerva) [Mailbox] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is: javax.ejb.EJBException [Mailbox] java.lang.RuntimeException: Unable to deregister with TransactionManager: java.lang.IllegalArgumentE xception: null xaRes [Mailbox] at org.opentools.minerva.jdbc.xa.XAConnectionFactory$2.closeConnection(XAConnec tionFactory.jav a:103) [Mailbox] at org.opentools.minerva.jdbc.xa.XAConnectionFactory$2.connectionClosed(XAConne ctionFactory.ja va:82) [Mailbox] at org.opentools.minerva.jdbc.xa.wrapper.XAConnectionImpl.clientConnectionClose d(XAConnectionI mpl.java:126) [Mailbox] at org.opentools.minerva.jdbc.xa.wrapper.XAClientConnection.close(XAClientConne ction.java:250) [Mailbox] at eon.infra.dss.BoxBean.loadBoxSummary(BoxBean.java:631)
[JBoss-dev] finder optimization(read-ahead) phase 3
All, Building off of danch's great work, I extended the read-ahead feature of CMP/JAWS New features: * the read-ahead flag is defaultable in standardjaws.xml and jaws.xml * The finder SQL select call and the LoadEntities SQL select call are now combined. Instead of 2 sql calls they are now one. * read-ahead is now extended to Single Entity finders and findByPrimaryKey. Enjoy, Bill
[JBoss-dev] CVS update: contrib/jetty/src/build build.xml
User: jules_gosnell Date: 01/06/21 15:18:23 Modified:jetty/src/build build.xml Log: add explicit configurations for various JBoss-Jetty properties Revision ChangesPath 1.7 +4 -1 contrib/jetty/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/build/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 2001/06/10 21:32:57 1.6 +++ build.xml 2001/06/21 22:18:23 1.7 @@ -1,5 +1,5 @@ ?xml version=1.0? -!-- $Id: build.xml,v 1.6 2001/06/10 21:32:57 jules_gosnell Exp $ -- +!-- $Id: build.xml,v 1.7 2001/06/21 22:18:23 jules_gosnell Exp $ -- !-- === -- @@ -205,6 +205,9 @@ replacevalue lt;mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jettygt; lt;attribute name=Configurationgt;file:../conf/jetty/jetty.xmllt;/attributegt; + lt;attribute name=WebDefaultgt;../../jetty/etc/webdefault.xmllt;/attributegt; + lt;attribute name=UnpackWarsgt;truelt;/attributegt; + lt;attribute name=PublishMBeansgt;falselt;/attributegt; lt;/mbeangt; lt;/servergt; ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JettyService.java
User: jules_gosnell
Date: 01/06/21 15:24:46
Modified:jetty/src/main/org/jboss/jetty JettyService.java
Log:
implement PublishMBeans property
ensure Service methods will not break if called more than once
general tidy up
Revision ChangesPath
1.16 +102 -64 contrib/jetty/src/main/org/jboss/jetty/JettyService.java
Index: JettyService.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JettyService.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- JettyService.java 2001/06/14 00:21:37 1.15
+++ JettyService.java 2001/06/21 22:24:46 1.16
@@ -36,7 +36,7 @@
*
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Julian Gosnell/a
- * @version $Revision: 1.15 $
+ * @version $Revision: 1.16 $
*/
class JettyMBean extends HttpServerMBean
@@ -85,22 +85,8 @@
// NOTES
-// 1. it would be better if performUndeploy() passed us the appData,
-// so we did not have to maintain our own warUrl:userData hashtable
+// Logging is in serious need of tidying up...
-// 2. DOM is not the fastest way of parsing an XML file. Does Scott
-// really need the DOM lying around after he has set up all the
-// naming? could he make use of the fact that Greg has already done a
-// pass over web.xml
-
-// 3. Can Greg provide me with a method for retrieving web.xml and
-// jboss-web.xml InputStreams ?
-
-// 4. Looks like Greg may have to split up his start() method so that
-// we can ensure that all naming and security services are started
-// before the webapp itself. We need to get at the jboss-web.xml file
-// and parse it before he fires up the webapp - or do we ??
-
public class JettyService extends AbstractWebContainer
implements JettyServiceMBean, MBeanRegistration
{
@@ -140,7 +126,7 @@
}
catch (Exception e)
{
- com.mortbay.Util.Log.event(Could not figure out JBOSS_HOME -
com.mortbay.HTTP.HttpServer displaced);
+ com.mortbay.Util.Log.warning(Could not figure out JBOSS_HOME -
com.mortbay.HTTP.HttpServer displaced);
}
return null;
@@ -190,8 +176,10 @@
{
// make a Jetty...
_jetty = new Jetty();
+
_jetty.setJettyHome(_jettyHome);
-_jetty.setWebDefault(_webDefault);
+_jetty.setWebDefault(getWebDefault());
+_jetty.setUnpackWars(getUnpackWars());
com.mortbay.Util.Log.event(Jetty instantiated and initialised);
@@ -201,20 +189,30 @@
}
protected void
-ensureMBean()
+ensureConfig()
{
-try
+// this must be done before config is read otherwise configs
+// defined therein will not receive MBean peers.
+if (getPublishMBeans())
{
- _mbean = new JettyMBean(_jetty);
- _server.registerMBean(_mbean, new ObjectName(_mbean.newObjectName(_server)));
-}
-catch (Exception e)
-{
- e.printStackTrace();
+ try
+ {
+ _mbean = new JettyMBean(_jetty);
+ _server.registerMBean(_mbean, new ObjectName(_mbean.newObjectName(_server)));
+ com.mortbay.Util.Log.event(MBean peers WILL be created for Jetty Contexts);
+ }
+ catch (Exception e)
+ {
+ e.printStackTrace();
+ }
+ catch (Error e)
+ {
+ e.printStackTrace();
+ }
}
-catch (Error e)
+else
{
- e.printStackTrace();
+ com.mortbay.Util.Log.event(MBean peers WILL NOT be created for Jetty
Contexts);
}
for (int i=0; i_configuration.size(); i++)
@@ -236,7 +234,7 @@
{
ensureProperties();
ensureJetty();
-ensureMBean();
+ensureConfig();
}
//
@@ -258,57 +256,58 @@
//
// 'service' interface
-
- // called by lifecycle methods as defined in ServiceMBeanSupport.
-
-
- // we should probably bind our instance of Jetty directly into our
- // own lifecycle, so that when init(), start(), stop() and destroy()
- // are called on us, the equivalent is done to our delegate.
-
- // How should we do it ?
-
- // a). We delegate to the JettyMBean which delegates to Jetty
- // b). We do it directly to Jetty and the MBean recieves notification if necessary
-
//
public void
initService()
throws Exception
{
-super.initService();
-
-try {ensureService();} catch (Exception e) {e.printStackTrace();}
+if (!isInitialised())
+{
+ super.initService();
+ try {ensureService();} catch (Exception e)
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty Jetty.java
User: jules_gosnell
Date: 01/06/21 15:20:12
Modified:jetty/src/main/org/jboss/jetty Jetty.java
Log:
sort out some logging
Revision ChangesPath
1.10 +1 -3 contrib/jetty/src/main/org/jboss/jetty/Jetty.java
Index: Jetty.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Jetty.java2001/06/13 23:01:27 1.9
+++ Jetty.java2001/06/21 22:20:12 1.10
@@ -98,7 +98,7 @@
setJettyHome(String jettyHome) // not public
{
System.setProperty(jetty.home, jettyHome);
-Log.event(setting jettyHome to +jettyHome);
+Log.event(setting JettyHome to +jettyHome);
}
public String
@@ -117,7 +117,6 @@
setUnpackWars(boolean unpackWars)
{
_unpackWars=unpackWars;
-Log.event(setting unpackWars to +_unpackWars);
}
public boolean
@@ -136,7 +135,6 @@
setWebDefault(String webDefault)
{
_webDefault=webDefault;
-Log.event(setting webDefault to +_webDefault);
}
public String
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problem with jaws.xml
Hi Geeks The recent standardjaws.xml fixed my problem. Thanx - Andy -Original Message- From: Mike Swainston-Rainford [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 3:03 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Problem with jaws.xml Andy the type-mappings will be in the standardjaws.xml file that Vincent updated. The deployer reads this first and likely isn't finding the PostgreSQL mapping because of the element name change. Probably a mismatch between the code changes in the metadata package and the element names in the standardjaws.xml. I think this will be reverted soon as per mails betwixt Scott and Vincent. Meantime check the version of the metadata classes and standardjaws.xml - if they are the updated ones that Vincent committed try checking out the previous versions instead and see if that fixes it. BTW which branch are you working on. I believe the updates have only been made on MAIN so far. Mike S-R At 10:31 21/06/2001 -0700, you wrote: Just as information the jaws.dtd looks like this: ?xml version=1.0 encoding=UTF-8? jaws datasourcejava:/PostgresDS/datasource type-mappingPostgreSQL/type-mapping enterprise-beans entity ejb-namejboss/survey/Survey/ejb-name table-nameSurvey/table-name create-tabletrue/create-table remove-tabletrue/remove-table cmp-field field-nameid/field-name column-nameId/column-name /cmp-field cmp-field field-namefirstName/field-name column-nameFirstName/column-name /cmp-field cmp-field field-namelastName/field-name column-nameLastName/column-name /cmp-field cmp-field field-namecompany/field-name column-nameCompany/column-name /cmp-field cmp-field field-nameemail/field-name column-nameEmail/column-name /cmp-field cmp-field field-namewebsite/field-name column-nameWebsite/column-name /cmp-field cmp-field field-namepermission/field-name column-namePermission/column-name /cmp-field cmp-field field-namejbossVersion/field-name column-nameJbossVersion/column-name /cmp-field cmp-field field-namejbossDownloadType/field-name column-nameJbossDownloadType/column-name /cmp-field cmp-field field-namejbossUsage/field-name column-nameJbossUsage/column-name /cmp-field cmp-field field-namejbossReason/field-name column-nameJbossReason/column-name /cmp-field cmp-field field-nameenvironmentEquipement/field-name column-nameEnvironmentEquipement/column-name /cmp-field cmp-field field-nameenvironmentOS/field-name column-nameEnvironmentOS/column-name /cmp-field cmp-field field-nameenvironmentProcessors/field-name column-nameEnvironmentProcessors/column-name /cmp-field cmp-field field-nameenvironmentRequests/field-name column-nameEnvironmentRequests/column-name /cmp-field cmp-field field-nameenvironmentDataSize/field-name column-nameEnvironmentDataSize/column-name /cmp-field cmp-field field-nameenvironmentStatelessEJBs/field-name column-nameEnvironmentStatelessEJBs/column-name /cmp-field cmp-field field-nameenvironmentStatefulEJBs/field-name column-nameEnvironmentStatefulEJBs/column-name /cmp-field cmp-field field-nameenvironmentEntityEJBs/field-name column-nameEnvironmentEntityEJBs/column-name /cmp-field cmp-field field-nameenvironmentMessageEJBs/field-name column-nameEnvironmentMessageEJBs/column-name /cmp-field cmp-field field-namejbossFeatures/field-name column-nameJbossFeatures/column-name /cmp-field cmp-field field-nameownInterceptors/field-name column-nameOwnInterceptors/column-name /cmp-field cmp-field field-nameownContainerInvokers/field-name column-nameOwnContainerInvokers/column-name /cmp-field cmp-field field-nameownMBeans/field-name column-nameOwnMBeans/column-name /cmp-field cmp-field field-nameownComments/field-name
[JBoss-dev] CVS update: binaries JBoss-2.2.2_Jetty-3.1.RC5-4.tgz
User: jules_gosnell Date: 01/06/21 16:25:19 Added: .JBoss-2.2.2_Jetty-3.1.RC5-4.tgz Log: This should fix the squabble between JBoss and Jetty for lifecycle management of Jetty MBeans Revision ChangesPath 1.1 binaries/JBoss-2.2.2_Jetty-3.1.RC5-4.tgz Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS RE: JmsSessionFactoryImpl.close()
Why does this thrown an exception? An example from sun from: http://java.sun.com/products/jms/tutorial/examples/client_ses_mdb/PublisherBean.java In the ejbRemote() method calls close() on the connection. Which is correct? Can someone tell me where the spec for this is, since Peter is going on vacation. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS thread usage
I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. Here is the breakdown of the top active threads in terms of the thread_count: last jboss code in the thread stack JMS ASF Threads: 29: org.jboss.jms.asf.ThreadPool$Slot.waitWhileEmpty(ThreadPool.java:181) SpySession Threads: 122: org.jbossmq.Mutex.waitLock DistributedJMSServerOIL Threads: 39: org.jbossmq.distributed.server.DistributedJMSServerOIL.run(DistributedJMSServerOIL.java:89) SpyConnection Thread: 38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99) ConnectionReceiverOIL Server 38: org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:110) Passivator Threads: 24: org.jboss.util.WorkerQueue.getJobImpl HyperSonic: 11: org.hsql.ServerConnection.run ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMS thread usage
Time to seriously look into what is up with that :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Thursday, June 21, 2001 8:05 PM |To: JBoss Dev |Subject: [JBoss-dev] JMS thread usage | | |I have been running the jbosstest suite off and on throughout the |day against |a snapshot of main on linux to look into the issue people have |reported concerning |running out of processes on linux. I am seeing a steady increase |in threads from |32 for the baseline just after startup to 229 after one interation |of the test suite to |329 after about 10 iterations of the test suite. | |Clearly were leaking threads and it could be that the test code is |not cleaning up |correctly, but I am seeing a large portion of the threads |associated with JMS and I |question why this should be. Out of the 329 threads there are 266 |JMS associated |threads. Here is the breakdown of the top active threads in terms of the |thread_count: last jboss code in the thread stack | | |JMS ASF Threads: |29: org.jboss.jms.asf.ThreadPool$Slot.waitWhileEmpty(ThreadPool.java:181) | |SpySession Threads: |122: org.jbossmq.Mutex.waitLock | |DistributedJMSServerOIL Threads: |39: |org.jbossmq.distributed.server.DistributedJMSServerOIL.run(Distribu |tedJMSServerOIL.java:89) | |SpyConnection Thread: |38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99) | |ConnectionReceiverOIL Server |38: |org.jbossmq.distributed.server.ConnectionReceiverOIL.run(Connection |ReceiverOIL.java:110) | |Passivator Threads: |24: org.jboss.util.WorkerQueue.getJobImpl | |HyperSonic: |11: org.hsql.ServerConnection.run | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
These are in theory complete re-implementations of the spec, clearly not the best - hey I did some of them myself. Marc and the board asked for this so that we could avoid any issues about distributing the sun jarfiles (some have licenses that don't allow people like jboss.org to distribute them). Maybe he can shed some more light on the issue. Clearly last time I pushed the jarfiles out I missed the client directory. My 2c for having a few less copies of each jarfile in CVS I suppose. Somebody went through and tried to make sure all the constants made them interoperable, though I can't swear that this is completely done yet. Feel free to go through and add the UID stuff, or at least file a bug so we know it needs to be done. Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 6/21/01 7:04 PM Subject: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar Why are there two *different* jboss-j2ee.jar files in the jboss module? 58456 Jun 21 15:52 ./src/client/jboss-j2ee.jar 61880 Jun 21 15:52 ./src/lib/jboss-j2ee.jar Why are we compiling these sources and not using the distributions from sun? I can understand that we might want to aggregate all of the jars from sun into one big one, but why recompile? I just ran into a very odd problem that could have been caused by this, though I have not tracked down the fix for it yet: java.io.InvalidClassException: javax.transaction.SystemException; Local class not compatible: stream classdesc serialVersionUID=-513218974312200874 local class serialVersionUID=839699079412719325 I looked at the source in the jboss-j2ee module and there are not serialVersionUID fields in SystemException, which means that every time this module is recompiled it will not be compatible with any other version... unless for some random lucky chance that javac re-generated all of the UID's the same as a previous build... it could happen, and I could also start thinking that Windows is the best software that the world has ever seen. My guess is that I ran into this because I am using the jta.jar from sun when building my components, though I am not 100% sure on this... close to it though. Can some one explain to me the rational for the jboss-j2ee module. I would suggest either chaging the module to aggregate from the sun .jar files, or to use the serialVersionUID from those jar files in the sources listed here. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/transaction SystemException.java
User: starksm
Date: 01/06/21 17:33:32
Modified:src/main/javax/transaction SystemException.java
Log:
Add the missing public int errorCode ivar so that the serialVersionUID
is consistent with that of the 1.3 RI j2ee.jar
Revision ChangesPath
1.2 +3 -1 jboss-j2ee/src/main/javax/transaction/SystemException.java
Index: SystemException.java
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/transaction/SystemException.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SystemException.java 2001/03/31 01:12:29 1.1
+++ SystemException.java 2001/06/22 00:33:32 1.2
@@ -10,10 +10,11 @@
it has encountered an unexpected error condition that prevents future
transaction services from proceeding.
-@version $Revision: 1.1 $
+@version $Revision: 1.2 $
*/
public class SystemException extends Exception
{
+public int errorCode;
/** Creates new codeSystemException/code without detail message.
*/
@@ -34,5 +35,6 @@
*/
public SystemException(int errcode)
{
+this.errorCode = errcode;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
Do NOT add serialVersionUID values as this is a missue that incorrectly addresses the problem. If the code is consistent it will have the correct serialVersionUID regardless of how the code is compiled. Somebody went through and tried to make sure all the constants made them interoperable, though I can't swear that this is completely done yet. Feel free to go through and add the UID stuff, or at least file a bug so we know it needs to be done. Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
This was an effort initiated by Marc due to some legal concerns. You'll
have to ping him for the details.
The serialVersionUID does not change simply because you recompile the
file and we should not just be fixing it because if they don't match it
indicates an inconsistent coding. For the problem class your showing javap on
the 1.3 RI j2ee.jar shows:
lib 1209javap -classpath j2ee.jar javax.transaction.SystemException
Compiled from SystemException.java
public class javax.transaction.SystemException extends java.lang.Exception {
public int errorCode;
public javax.transaction.SystemException();
public javax.transaction.SystemException(java.lang.String);
public javax.transaction.SystemException(int);
}
while the javax.transaction.SystemException in jboss-j2ee is:
public class SystemException extends Exception
{
/** Creates new codeSystemException/code without detail message.
*/
public SystemException()
{
}
/** Constructs an codeSystemException/code with the specified detail message.
@param msg the detail message.
*/
public SystemException(String msg)
{
super(msg);
}
/** Constructs an codeSystemException/code with the specified detail message.
@param errcode the error code for the exception
*/
public SystemException(int errcode)
{
}
}
This shows that the class is missing the 'public int errorCode;' ivar, hench the
serialVersionUID mismatch as it should be. Fix the source recompile on a
linux box and now the serialVersionUID matches that from the 1.3 RI
j2ee.jar:
bash-2.04$ serialver -classpath /tmp/JBoss_2_4/jboss-j2ee/src/main
javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID =
839699079412719325L;
lib 1210serialver -classpath j2ee.jar javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID =
839699079412719325L;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
Ah, the real bug shows it's ugly head. We'll get that one!
Thanks Scott.
-Original Message-
From: Scott M Stark
To: JBoss Dev
Sent: 6/21/01 8:36 PM
Subject: Re: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
This was an effort initiated by Marc due to some legal concerns. You'll
have to ping him for the details.
The serialVersionUID does not change simply because you recompile the
file and we should not just be fixing it because if they don't match it
indicates an inconsistent coding. For the problem class your showing
javap on
the 1.3 RI j2ee.jar shows:
lib 1209javap -classpath j2ee.jar javax.transaction.SystemException
Compiled from SystemException.java
public class javax.transaction.SystemException extends
java.lang.Exception {
public int errorCode;
public javax.transaction.SystemException();
public javax.transaction.SystemException(java.lang.String);
public javax.transaction.SystemException(int);
}
while the javax.transaction.SystemException in jboss-j2ee is:
public class SystemException extends Exception
{
/** Creates new codeSystemException/code without detail message.
*/
public SystemException()
{
}
/** Constructs an codeSystemException/code with the specified
detail message.
@param msg the detail message.
*/
public SystemException(String msg)
{
super(msg);
}
/** Constructs an codeSystemException/code with the specified
detail message.
@param errcode the error code for the exception
*/
public SystemException(int errcode)
{
}
}
This shows that the class is missing the 'public int errorCode;' ivar,
hench the
serialVersionUID mismatch as it should be. Fix the source recompile on a
linux box and now the serialVersionUID matches that from the 1.3 RI
j2ee.jar:
bash-2.04$ serialver -classpath /tmp/JBoss_2_4/jboss-j2ee/src/main
javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID
= 839699079412719325L;
lib 1210serialver -classpath j2ee.jar javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID
= 839699079412719325L;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
Neato. I did not know that. =]
Just curious but what are the licensing restrictions from sun on
distributing there jar files?
--jason
On Thu, 21 Jun 2001, Scott M Stark wrote:
This was an effort initiated by Marc due to some legal concerns. You'll
have to ping him for the details.
The serialVersionUID does not change simply because you recompile the
file and we should not just be fixing it because if they don't match it
indicates an inconsistent coding. For the problem class your showing javap on
the 1.3 RI j2ee.jar shows:
lib 1209javap -classpath j2ee.jar javax.transaction.SystemException
Compiled from SystemException.java
public class javax.transaction.SystemException extends java.lang.Exception {
public int errorCode;
public javax.transaction.SystemException();
public javax.transaction.SystemException(java.lang.String);
public javax.transaction.SystemException(int);
}
while the javax.transaction.SystemException in jboss-j2ee is:
public class SystemException extends Exception
{
/** Creates new codeSystemException/code without detail message.
*/
public SystemException()
{
}
/** Constructs an codeSystemException/code with the specified detail message.
@param msg the detail message.
*/
public SystemException(String msg)
{
super(msg);
}
/** Constructs an codeSystemException/code with the specified detail message.
@param errcode the error code for the exception
*/
public SystemException(int errcode)
{
}
}
This shows that the class is missing the 'public int errorCode;' ivar, hench the
serialVersionUID mismatch as it should be. Fix the source recompile on a
linux box and now the serialVersionUID matches that from the 1.3 RI
j2ee.jar:
bash-2.04$ serialver -classpath /tmp/JBoss_2_4/jboss-j2ee/src/main
javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID =
839699079412719325L;
lib 1210serialver -classpath j2ee.jar javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID =
839699079412719325L;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS thread usage
I'm embarased. I'll look into it right away. Since the JMS client and server stuff is running in the same VM when using ASF I should be able to get rid of the socket calls and thus free up the threads that are polling the sockets. I'll also see if I can get rid of the SpySession Threads when using the ASF.. Regards, Hiram - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:04 PM Subject: [JBoss-dev] JMS thread usage I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. Here is the breakdown of the top active threads in terms of the thread_count: last jboss code in the thread stack JMS ASF Threads: 29: org.jboss.jms.asf.ThreadPool$Slot.waitWhileEmpty(ThreadPool.java:181) SpySession Threads: 122: org.jbossmq.Mutex.waitLock DistributedJMSServerOIL Threads: 39: org.jbossmq.distributed.server.DistributedJMSServerOIL.run(DistributedJMSSer verOIL.java:89) SpyConnection Thread: 38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99) ConnectionReceiverOIL Server 38: org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverO IL.java:110) Passivator Threads: 24: org.jboss.util.WorkerQueue.getJobImpl HyperSonic: 11: org.hsql.ServerConnection.run ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
I really like the way you designed this: the PreloadFinderCommand acting as a decorator really makes things clearer. This is getting faster everytime one of us touches it. Something I noticed, Bill - your changes only worked for defined finders. I've extended them so that they work for findAll and the regular autogenerated findByField stuff as well. To support this I changed the 'defined' member of JDBCPreloadFinderCommand to be a JDBCFinderCommand (superclass of all finders) and made his setParameters method simply delegate to the embedded finder command. I also changed the name of the embedded finder to finderDelegate: I think that's more descriptive now. I'm going to test that a bit more, then check in. -danch [EMAIL PROTECTED] wrote: User: patriot1burke Date: 01/06/21 14:57:22 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS thread usage
Chris' nightly test runs have only been failing with these OutOfMemory exceptions for the last couple of nights. Either it was a recent change that caused this or a recently added test that brought it into the open -danch Hiram Chirino wrote: I'm embarased. I'll look into it right away. Since the JMS client and server stuff is running in the same VM when using ASF I should be able to get rid of the socket calls and thus free up the threads that are polling the sockets. I'll also see if I can get rid of the SpySession Threads when using the ASF.. Regards, Hiram - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:04 PM Subject: [JBoss-dev] JMS thread usage I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/lib jboss-jdbc_ext.jar
User: chirino Date: 01/06/21 20:16:41 Added: src/lib jboss-jdbc_ext.jar Log: The new JDBC persistence layer has a dependency on this lib. Revision ChangesPath 1.1 jbossmq/src/lib/jboss-jdbc_ext.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jbossmq/jdbcpersistence - New directory
User: chirino Date: 01/06/21 20:12:05 jbossmq/src/main/org/jbossmq/jdbcpersistence - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jbossmq SpyConnection.java SpyMessageConsumer.java SpySession.java
User: chirino
Date: 01/06/21 20:16:02
Modified:src/main/org/jbossmq SpyConnection.java
SpyMessageConsumer.java SpySession.java
Log:
The Spy sessions and SypConnections now use a single system wide Thread
Pool for all async task that occur. This should help reduce the number of
threads that used when using multiple connections or if messages are being
delivered with the help of a MDB.
Revision ChangesPath
1.7 +45 -25jbossmq/src/main/org/jbossmq/SpyConnection.java
Index: SpyConnection.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jbossmq/SpyConnection.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- SpyConnection.java2001/05/13 08:51:31 1.6
+++ SpyConnection.java2001/06/22 03:16:02 1.7
@@ -32,13 +32,15 @@
import org.jbossmq.distributed.interfaces.ConnectionReceiver;
import org.jbossmq.distributed.interfaces.DistributedJMSServer;
+import EDU.oswego.cs.dl.util.concurrent.*;
+
/**
* This class implements javax.jms.Connection
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
*
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class SpyConnection implements java.io.Serializable, javax.jms.Connection {
//
@@ -90,19 +92,7 @@
crClassName = crCN;
spyXAResourceManager = new SpyXAResourceManager(this);
- // Stop Asynch based programs from exiting out due to no
- // non-deamon threads running. We start one here that lives
- // untill the connection is closed().
- connectionThread = new Thread(SpyConnection Thread) {
- synchronized public void run() {
- try {
- this.wait(); // Wait for close() to stop me
- } catch ( InterruptedException e ) {
- }
- }
- };
- connectionThread.start();
-
+ openExecutor();
}
//
@@ -231,14 +221,8 @@
failureHandler(e, Cannot close properly the connection);
}
Log.log(Disconnected from server);
-
- // Stop the non deamon thread that we created.
- synchronized (connectionThread) {
- connectionThread.notify();
- connectionThread.interrupt();
- }
-
+ closeExecutor();
// Only set the closed flag after all the objects that depend
// on this connection have been closed.
closed = true;
@@ -588,11 +572,47 @@
failureHandler(e, Cannot acknowlege a message.);
}
}
+
+
- // The connectionThread is a non-deamon thread that
- // runs until the connection is closed(). This allows
- // Writing asynch client programs that do not create
+ // The Executor holds a pool non-deamon threads that
+ // service all the async tasks on the client.
+ // We make this a class varibale to get better pooling.
+ //
+ // We will also keep a count of how many instances of the SpyConnections
+ // there are so we can destroy the Executor once it is not
+ // needed. This will also allow us to cope with
+ // asynch client programs that do not create
// long running threads. The program would terminate when
// the connection is closed()
- Thread connectionThread;
+ static public Executor execeutor;
+ static private int spyConnectionCounter=0;
+
+ synchronized private void closeExecutor() {
+ spyConnectionCounter--;
+ if( spyConnectionCounter == 0 ) {
+
((PooledExecutor)execeutor).shutdownAfterProcessingCurrentlyQueuedTasks();
+ }
+ }
+
+ synchronized private void openExecutor() {
+ if (spyConnectionCounter == 0) {
+
+ // Using a bounded buffer of 10 tasks, at least 4 threads (started only
+ // when needed due to incoming requests), but allowing
+ // up to 100 threads if the buffer gets full.
+ // allowing them to die if they are not used for 1 minute.
+ /// clients block if both the buffer is full and all 100 threads are
busy:
+ PooledExecutor pool = new PooledExecutor();
+ pool = new PooledExecutor(new
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCCommandFactory.java JDBCPreloadFinderCommand.java
User: danch
Date: 01/06/21 20:24:49
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCCommandFactory.java
JDBCPreloadFinderCommand.java
Log:
extended Bill's earlier work to work on findAll and findBy commands as well
Revision ChangesPath
1.34 +10 -1 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JDBCCommand.java 2001/06/18 14:34:27 1.33
+++ JDBCCommand.java 2001/06/22 03:24:49 1.34
@@ -57,7 +57,11 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.33 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
+ * @version $Revision: 1.34 $
+ *
+ * Revision:
+ * 20010621 danch: add getter for name
*/
public abstract class JDBCCommand
{
@@ -125,6 +129,11 @@
this.debug = factory.getDebug();
}
+ /** return the name of this command */
+ public String getName() {
+ return name;
+ }
+
// Protected -
/**
1.12 +30 -12
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JDBCCommandFactory.java 2001/06/21 21:55:01 1.11
+++ JDBCCommandFactory.java 2001/06/22 03:24:49 1.12
@@ -69,11 +69,13 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=[EMAIL PROTECTED]danch (Dan Christopherson)/a
* @author a href=[EMAIL PROTECTED]Bill Burke/a
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*
* Revision:
* 20010621 Bill Burke: createDefinedFinderCommand creates different objects
- * based on the read-head flag of the FinderMetaData.
+ *based on the read-head flag of the FinderMetaData.
+ * 20010621 danch: extended Bill's change to work on other finder types;
+ *removed stale todos.
*/
public class JDBCCommandFactory implements JPMCommandFactory
{
@@ -95,12 +97,10 @@
/** a map of data preloaded within some transaction for some entity. This map
* is keyed by Transaction and the data are hashmaps with key = entityKey and
-* data = Object[] containing the entity data.
-* @todo use weak references to ease memory. */
+* data = Object[] containing the entity data. */
private Map preloadedData = new HashMap();
/** A map of data preloaded without a transaction context. key=entityKey,
* data = Object[] containing entity data
-* @todo use weak references to ease memory.
*/
private Map nonTransactionalPreloadData = new HashMap();
@@ -125,7 +125,7 @@
{
this.container = container;
this.log = log;
-
+
this.javaCtx = (Context)new InitialContext().lookup(java:comp/env);
String ejbName = container.getBeanMetaData().getEjbName();
@@ -144,10 +144,10 @@
if (metadata == null) {
throw new DeploymentException(No metadata found for bean + ejbName);
}
-
+
tm = (TransactionManager) container.getTransactionManager();
- softRefHandler.schedule(new PreloadRefQueueHandlerTask(), 50);
+ softRefHandler.schedule(new PreloadRefQueueHandlerTask());
}
// Public
@@ -195,7 +195,14 @@
public JPMFindEntitiesCommand createFindAllCommand(FinderMetaData f)
{
- return new JDBCFindAllCommand(this, f);
+ if (f.hasReadAhead())
+ {
+ return new JDBCPreloadFinderCommand(this, new JDBCFindAllCommand(this, f));
+ }
+ else
+ {
+ return new JDBCFindAllCommand(this, f);
+ }
}
public JPMFindEntitiesCommand createDefinedFinderCommand(FinderMetaData f)
@@ -213,7 +220,14 @@
public JPMFindEntitiesCommand createFindByCommand(Method finderMethod,
FinderMetaData f)
throws IllegalArgumentException
{
- return new JDBCFindByCommand(this, finderMethod, f);
+ if (f.hasReadAhead())
+ {
+ return new JDBCPreloadFinderCommand(this, new JDBCFindByCommand(this,
finderMethod, f));
+ }
+ else
Re: [JBoss-dev] Deployable service archives new configurationsystem
Wow, I just starting reading some of this again and I can't believe how I made all of those grammatical errors. Yikes! I had one more bit to add to this, which is probably even less thought out than what I wrote here. That is that eventually I would like to have each JBoss server start up and discover its configuration by itself, perhaps through JINI or something JINI-like. I do not think this would be very difficult with the changes that need to be in place to load from a URL. If the core component which started things up (aside from the bootloader aka. Main), was pluggable via system properties, then we could replace the bit that took the URL from the command line and replace it with one that would discover the URL that it should use. So I guess something like a URLFactory might work, but that seems like it might be an ugly solution. Main could startup, do whatever, then create the URLFactory as specified by properties (or default to the CommandLineURLFactory), then call factory.getURL() to continue. That might work, though I am not really fond off it. Either way, the concept of creating an object that would abstract the url would allow a JINI-like instance to detect the url that a given server should use. So, assuming the not-so-nice URLFactory the server might be started like: ./jboss/bin/run.sh -Dorg.jboss.Main.factoryType=org.jboss.jini.JiniURLFactory Any ways, I am not really sure the exact details, but I think that something like this would be realativly easy to implement and would allow the server to be even more pluggable. For the record I am not suggesting the usage of a URLFactory like above by any means, that seems a bit wrong. It serves to show what I am talking about though... at least I think it does. No birds were harmed durring the creation of this email... --jason On Wed, 20 Jun 2001, Jason Dillon wrote: Howdy, I have been thinking about this for a while (actually I have been think about something like this for years, but never really had the resource to be anything together). I am thinking that it would be incredibly cool (and usable) to package up services into deployable jar files (perhaps .sar or something). These files would have a descriptor that could tell which service classes are available and provide some extra metadata, like the name of the configuration they should use. On the server side, there is a Service Deployer (and probably a Service Manager, though that might be the JMX Agent) as well as a Service Configuration Manager. The service deployer and service manager would be collectively responsible for discovering services to install. Once the service classes have been loader (probably in there one class loader, perhaps with some extra loaders for dependency libraries too), the manager will ask the configuration service for the services configuration. Services would be JMX MBeans. They could be wrapped in dynamic mbeans, so services do not have to worry about the JMX bits. Blah, blah, blah. Services could received events if there configuration changes (ala the configuration service), and optional reload if they can. * * * I could go on drooling over this in more detail, but how about some explanation for why I think this would be a positive move for JBoss. First it would make it trivial to integrate thirdparty components, such as Tomcat or Jetty. Users would install the base JBoss server, then download the optional services which they desire, then simply tell the configuration service about the new component and drop a file into the deployment directory. All of the above components (deployer, manager config) would be pluggable themselves for maximum extensively. I would imaging that the first configuration service would work off of files (probably a standard .xml file for defining properties and such for a service (or services) and a method to include other urls (such as jetty.xml or log4j.xml). So in the simplest configuration a user could drop a file into the conf directory (say log4j.xml) and a file into the deploy directory (say log4j.sar). The deployer would be watching for file, find a new file, read the deployment descriptor, tell the manager to install it, the manager would then ask the config service for the log4j configuration, which would return an InputStream (or perhaps an abstraction of the basic properties and url access) and ask the service to configure itself. If the user wanted to change something, they could just edit the log4j.xml file, which would cause the config service to send an event to the manager (and it to the service) that its configuration has changed. If the service could handle a reconfig it would request the latest config from the manager (and it from the config service). In this case the manger would be the go between from the service and the config manager (as well as the deployer and possibility an extra library manager). * * * At this point
RE: [JBoss-dev] Deployable service archives new configuration system
hey... just an update. I believe the break down is as follow, the inspiration comes from unix sys-admin. You don't deploy systems and applications in unix (it is a vague term in J2EE a problem really), you install, configure, and start/stop. (the deploy in JBoss covers all these right now) This is the natural administration approach and break down of tasks. We won't do better. You have ServiceInstallerMBean, a ServiceConfiguratorMBean, and the ServiceControllerMBean. The ServiceInstaller can also download stuff from the web and manage local copies of .jar with the help of a library manager (to be written). It is much much clearer I am tired of the crap people throw around when they say deploy... time to be precise. will try to post something sometime next week, I need to really work on this... still very green, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Wednesday, June 20, 2001 11:43 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Deployable service archives new configuration |system | | | |I am thinking that it would be incredibly cool (and usable) to |package up | |services into deployable jar files (perhaps .sar or something). | | yes, the xml+class=.sar I don't know... but yes | |xml in this term is not service configuration. I did not want to have to |create a new .sar each time I wanted to have the smae service with a minor |config change. I suppose that it could contain actually service config (or |more correctly some tag that references a xml config file in the .sar for |services which contain no extra or static configuation. | |a complete side note, it might be nice to have a CommandService or |something |like it, which executes through the same channel as a service, but will |unbind itself once it has done it's job. This would be nice for something |that needed to do some thing once (like add to the classpath) then will |never be needed again... any ways, side note. | | |The service deployer and service manager would be collectively |responsible | |for discovering services to install. Once the service |classes have been | | This is misleading, we can call the API (through JMX and/or |Adaptors) or we | can use the scanner. | |I am not really sure what you mean by this. Is what I said misleading? | | |loader (probably in there one class loader, perhaps with some |extra loaders | |for dependency libraries too), the manager will ask the | |configuration service | |for the services configuration. | | I see. The manager might be superflous need to check. | |It might be, I was thinking that one component should load, then |ask another |to manage it's state. In this case if there was a library loading |mechanism |then it would make more sence for a manager type to deal with that. The |deployer would create the ClassLoader for the service, read the descriptor |then call the manager: | | serviceManager.addService(ServiceDescriptor, ClassLoader, ...); | |or something like that. You are right though, I only started |thinking about |this in more detail last night. | | that I don't see (the dynamic part ... worry about JMX etc etc...) please | explain | |I know that currently services are all MBeans. What I mean here is that |services do not really have to provide a MBean interface if they |do not want |to. We could provide a simple wrapper around the service which would |introspect to find all operations attributes. | |All that I meant was that if a service did not want to deal with any of the |MBean stuff, but wanted to participate, we could wrap it automatically (and |would have to actually). | |Does that make it more or less clear? | | yes I coded that yesterday. It seems *someone* is sending a |message and we | are a few to recieve it. It seems your reception was quite |clear, clearer | than mine, so I thank you for sharing your dream... | |Well strictly speaking my dream, is to have services packaged up |into .sar |files, allow them to be dynamically deployed and have the configuation of |these services abstracted out. | |I have read most of your emails, though durring the week of JavaOne and |perhaps a little after, I had so many messages that I could not get |other work (that pays) done, so I might have missed something. | |I have always been into configuation management of one sort. At Mpath |Interactive, I started working on a system called SANITY, System |And Network |moNitor ThingY, which was aiming to do what I described above + all |of the bits you are working on and the rest of what JBoss already is. The |purpose of SANITY was to provide a common service-oriented framework for |managing the configuation of services across a very large number |of machines |distributed across the country. | |I spent some time prototyping this and filled up a few notebooks |with ideas, |but never got very far, because I was the only engineer in |operations... and |I could not handle the size of it all
[JBoss-dev] CVS update: manual/src/docs customizingjaws.xml
User: danch Date: 01/06/21 20:47:40 Modified:src/docs customizingjaws.xml Log: added brief/terse explanation of the interaction between read-ahead option and transactions Revision ChangesPath 1.9 +267 -259 manual/src/docs/customizingjaws.xml Index: customizingjaws.xml === RCS file: /cvsroot/jboss/manual/src/docs/customizingjaws.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- customizingjaws.xml 2001/06/16 00:49:32 1.8 +++ customizingjaws.xml 2001/06/22 03:47:40 1.9 @@ -1,15 +1,15 @@ ?xml version = 1.0 encoding = UTF-8? chapter id=jaws - titleCustomizing JAWS/title - paraAuthor:author - firstnameSebastien/firstname - surnameAlborini/surname - /author - email[EMAIL PROTECTED]/email - /para - section - titleIntroduction/title - paraJAWS is the O/R mapper used by JBoss to manage CMP entity beans. JAWS is configured in a file named standardjaws.xml, located in the conf/config-name directory in the JBoss distribution. The default quoteconfig-name/quote is quotedefault/quote./para + titleCustomizing JAWS/title + paraAuthor:author + firstnameSebastien/firstname + surnameAlborini/surname + /author + email[EMAIL PROTECTED]/email + /para + section + titleIntroduction/title + paraJAWS is the O/R mapper used by JBoss to manage CMP entity beans. JAWS is configured in a file named standardjaws.xml, located in the conf/config-name directory in the JBoss distribution. The default quoteconfig-name/quote is quotedefault/quote./para paraThis file configures JAWS for all JBoss. You can then extend this configuration on a per-application basis by putting a jaws.xml @@ -21,91 +21,91 @@ directory of the emphasisjar/emphasis archive. /para - paraHere is what you can do with standardjaws.xml / jaws.xml:/para - itemizedlist - listitem - para Specify a datasource and the type-mappings to use with it - /para - /listitem - listitem - para Set a bunch of options concerning jaws behavior - /para - /listitem - listitem - para Specify how JAWS should build/use your tables - /para - /listitem - listitem - para Define finders to access you entity beans - /para - /listitem - listitem - para Define a type mapping - /para - /listitem - /itemizedlist - paraIf you want to know everything about jaws.xml, see the Jaws.xml DTD. The + paraHere is what you can do with standardjaws.xml / jaws.xml:/para + itemizedlist + listitem +para Specify a datasource and the type-mappings to use with it + /para + /listitem + listitem +para Set a bunch of options concerning jaws behavior + /para + /listitem + listitem +para Specify how JAWS should build/use your tables + /para + /listitem + listitem +para Define finders to access you entity beans + /para + /listitem + listitem +para Define a type mapping + /para + /listitem + /itemizedlist + paraIf you want to know everything about jaws.xml, see the Jaws.xml DTD. The general structure of the jaws.xml can be found here. All parts of this file are optional: you only provide what you need!/para - /section - section - titleSpecifying a datasource/title - paraA datasource is, mainly, a database plus a driver plus a connection pool. By + /section + section + titleSpecifying a datasource/title + paraA datasource is, mainly, a database plus a driver plus a connection pool. By default, jboss uses the Hypersonic datasource. To add another datasource, you have to declare it as a JMX MLet: see the manual./para - paraThe second ARG of this MLet is the JNDI name of the datasource, i.e. the name + paraThe second ARG of this MLet is the JNDI name of the datasource, i.e. the name you have to use to access it. To tell JAWS to use this datasource, simply add in your jaws.xml file a
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss_2_4.dtd
User: starksm Date: 01/06/21 20:52:14 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jboss_2_4.dtd Log: Add an unauthenticated-principal element at the application level to allow for the specification of the principal name that should be returned by EJBContext.getCallerPrincipal(). Revision ChangesPath No revision No revision 1.1.2.1 +9 -1 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 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- jboss_2_4.dtd 2001/06/15 16:14:08 1.1 +++ jboss_2_4.dtd 2001/06/22 03:52:14 1.1.2.1 @@ -13,6 +13,7 @@ enforce-ejb-restrictions / security-domain / + unauthenticated-principal / enterprise-beans @@ -84,7 +85,7 @@ 3- the deployer can specify runtime jndi names for resource managers. -- -!ELEMENT jboss (enforce-ejb-restrictions? , security-domain? , enterprise-beans? , resource-managers? , container-configurations?) +!ELEMENT jboss (enforce-ejb-restrictions? , security-domain? , unauthenticated-principal?, enterprise-beans? , resource-managers? , container-configurations?) !-- The enforce-ejb-restrictions element tells the container to enforce ejb1.1 restrictions @@ -107,6 +108,13 @@ Used in: jboss, container-configuration -- !ELEMENT security-domain (#PCDATA) + +!-- The unauthenticated-principal element specifies the name of the principal +that will be returned by the EJBContext.getCallerPrincipal() method if there +is no authenticated user. This Principal has no roles or privaledges to call +any other beans. +-- +!ELEMENT unauthenticated-principal (#PCDATA) !-- The enterprise-beans element contains additional information about ___ Jboss-development mailing list [EMAIL PROTECTED] http://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/06/21 20:54:24 Modified:src/resources/org/jboss/metadata jboss_2_4.dtd Log: Add an unauthenticated-principal element at the application level to allow for the specification of the principal name that should be returned by EJBContext.getCallerPrincipal(). Revision ChangesPath 1.2 +9 -1 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 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss_2_4.dtd 2001/06/15 16:14:08 1.1 +++ jboss_2_4.dtd 2001/06/22 03:54:24 1.2 @@ -13,6 +13,7 @@ enforce-ejb-restrictions / security-domain / + unauthenticated-principal / enterprise-beans @@ -84,7 +85,7 @@ 3- the deployer can specify runtime jndi names for resource managers. -- -!ELEMENT jboss (enforce-ejb-restrictions? , security-domain? , enterprise-beans? , resource-managers? , container-configurations?) +!ELEMENT jboss (enforce-ejb-restrictions? , security-domain? , unauthenticated-principal?, enterprise-beans? , resource-managers? , container-configurations?) !-- The enforce-ejb-restrictions element tells the container to enforce ejb1.1 restrictions @@ -107,6 +108,13 @@ Used in: jboss, container-configuration -- !ELEMENT security-domain (#PCDATA) + +!-- The unauthenticated-principal element specifies the name of the principal +that will be returned by the EJBContext.getCallerPrincipal() method if there +is no authenticated user. This Principal has no roles or privaledges to call +any other beans. +-- +!ELEMENT unauthenticated-principal (#PCDATA) !-- The enterprise-beans element contains additional information about ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EnterpriseContext.java
User: starksm
Date: 01/06/21 20:58:55
Modified:src/main/org/jboss/ejb EnterpriseContext.java
Log:
Update getCallerPrincipal() to check for a getUnauthenticatedPrincipal()
value in the absence of a caller principal and a security domain
Revision ChangesPath
1.35 +35 -16jboss/src/main/org/jboss/ejb/EnterpriseContext.java
Index: EnterpriseContext.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EnterpriseContext.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- EnterpriseContext.java2001/06/21 05:14:31 1.34
+++ EnterpriseContext.java2001/06/22 03:58:55 1.35
@@ -30,7 +30,9 @@
import javax.transaction.HeuristicRollbackException;
import org.jboss.logging.Logger;
+import org.jboss.metadata.ApplicationMetaData;
import org.jboss.metadata.SecurityRoleRefMetaData;
+import org.jboss.security.RealmMapping;
import org.jboss.security.SimplePrincipal;
/**
@@ -44,7 +46,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.34 $
+ * @version $Revision: 1.35 $
*/
public abstract class EnterpriseContext
{
@@ -64,10 +66,10 @@
Transaction transaction;
// The principal associated with the call
- Principal principal;
+ private Principal principal;
// The principal for the bean associated with the call
- Principal beanPrincipal;
+ private Principal beanPrincipal;
// Only StatelessSession beans have no Id, stateful and entity do
Object id;
@@ -196,21 +198,38 @@
{
throw new EJBException(Deprecated);
}
-
- public Principal getCallerPrincipal()
- {
- if (beanPrincipal == null principal != null)
+
+ /** Get the Principal for the current caller. This method
+cannot return null according to the ejb-spec.
+ */
+ public Principal getCallerPrincipal()
+ {
+ if( beanPrincipal == null )
+ {
+ RealmMapping rm = con.getRealmMapping();
+ if( principal != null )
{
- if( con.getRealmMapping() == null ) {
- beanPrincipal = principal;
- } else {
- beanPrincipal = con.getRealmMapping().getPrincipal(principal);
- }
+if( rm != null )
+ beanPrincipal = rm.getPrincipal(principal);
+else
+ beanPrincipal = principal;
}
- else if( beanPrincipal == null con.getRealmMapping() == null )
- throw new IllegalStateException(No security context set);
- return beanPrincipal;
- }
+ else if( rm != null )
+ { // Let the RealmMapping map the null principal
+beanPrincipal = rm.getPrincipal(principal);
+ }
+ else
+ { // Check for a unauthenticated principal value
+ApplicationMetaData appMetaData =
con.getBeanMetaData().getApplicationMetaData();
+String name = appMetaData.getUnauthenticatedPrincipal();
+if( name != null )
+ beanPrincipal = new SimplePrincipal(name);
+ }
+ }
+ if( beanPrincipal == null )
+ throw new IllegalStateException(No security context set);
+ return beanPrincipal;
+ }
public EJBHome getEJBHome()
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jbossmq/server StartServer.java
User: chirino
Date: 01/06/21 21:04:43
Modified:src/main/org/jbossmq/server StartServer.java
Log:
I have added an new INVM that can only be used when the JBossMQ server is
running in the same machine as the client. This INVM IL theoreticaly is the
epitomy of performance since no serialization occurs and no threads are
needs to poll for input.
Revision ChangesPath
1.6 +18 -5 jbossmq/src/main/org/jbossmq/server/StartServer.java
Index: StartServer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jbossmq/server/StartServer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- StartServer.java 2001/05/22 07:29:02 1.5
+++ StartServer.java 2001/06/22 04:04:43 1.6
@@ -38,6 +38,8 @@
import org.jbossmq.distributed.interfaces.DistributedConnectionFactory;
import org.jbossmq.distributed.interfaces.DistributedJMSServer;
+import org.jboss.naming.NonSerializableFactory;
+
/**
* Class used to start a JMS service. This can be called from inside another
@@ -48,7 +50,7 @@
* @author Vincent Sheffer ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
*
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class StartServer implements Runnable
{
@@ -234,10 +236,21 @@
new
ObjectName(JMS:service=DistributedConnectionFactory,type=+name));
//(re)bind the connection factories in the JNDI
namespace
-
ctx.rebind(topicConnectionFactoryJNDI,invocationLayerFactory.spyTopicConnectionFactory);
-
ctx.rebind(queueConnectionFactoryJNDI,invocationLayerFactory.spyQueueConnectionFactory);
-
ctx.rebind(xaTopicConnectionFactoryJNDI,invocationLayerFactory.spyXATopicConnectionFactory);
-
ctx.rebind(xaQueueConnectionFactoryJNDI,invocationLayerFactory.spyXAQueueConnectionFactory);
+ try {
+
ctx.rebind(topicConnectionFactoryJNDI,invocationLayerFactory.spyTopicConnectionFactory);
+
ctx.rebind(queueConnectionFactoryJNDI,invocationLayerFactory.spyQueueConnectionFactory);
+
ctx.rebind(xaTopicConnectionFactoryJNDI,invocationLayerFactory.spyXATopicConnectionFactory);
+
ctx.rebind(xaQueueConnectionFactoryJNDI,invocationLayerFactory.spyXAQueueConnectionFactory);
+
+ // If the object could not be stored, it could be
because it is only meant to
+ // be used for intra JVM usage... Lets try to bind it
using
+ } catch ( javax.naming.CommunicationException ignore )
{
+ // Try to store factorys as NonSerializable
objects.
+
NonSerializableFactory.rebind(ctx,topicConnectionFactoryJNDI,invocationLayerFactory.spyTopicConnectionFactory);
+
NonSerializableFactory.rebind(ctx,queueConnectionFactoryJNDI,invocationLayerFactory.spyQueueConnectionFactory);
+
NonSerializableFactory.rebind(ctx,xaTopicConnectionFactoryJNDI,invocationLayerFactory.spyXATopicConnectionFactory);
+
NonSerializableFactory.rebind(ctx,xaQueueConnectionFactoryJNDI,invocationLayerFactory.spyXAQueueConnectionFactory);
+ }
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jbossmq/distributed/server ConnectionReceiverINVM.java DistributedJMSServerINVM.java
User: chirino
Date: 01/06/21 21:04:43
Added: src/main/org/jbossmq/distributed/server
ConnectionReceiverINVM.java
DistributedJMSServerINVM.java
Log:
I have added an new INVM that can only be used when the JBossMQ server is
running in the same machine as the client. This INVM IL theoreticaly is the
epitomy of performance since no serialization occurs and no threads are
needs to poll for input.
Revision ChangesPath
1.1
jbossmq/src/main/org/jbossmq/distributed/server/ConnectionReceiverINVM.java
Index: ConnectionReceiverINVM.java
===
/*
* JBossMQ, the OpenSource JMS implementation
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jbossmq.distributed.server;
import javax.jms.Destination;
import javax.jms.JMSException;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import org.jbossmq.Log;
import org.jbossmq.SpyConnection;
import org.jbossmq.distributed.interfaces.ConnectionReceiver;
import org.jbossmq.distributed.interfaces.ConnectionReceiverSetup;
import org.jbossmq.ReceiveRequest;
import org.jbossmq.SpyDestination;
/**
*The RMI implementation of the ConnectionReceiver object
*
*@author Norbert Lataille ([EMAIL PROTECTED])
*@author Hiram Chirino ([EMAIL PROTECTED])
*
*@version $Revision: 1.1 $
*/
public class ConnectionReceiverINVM implements ConnectionReceiver,
ConnectionReceiverSetup
{
// Attributes
//A link on my connection
private SpyConnection connection;
//Is my connection closed ?
private boolean closed;
// Constructor ---
public ConnectionReceiverINVM() throws RemoteException
{
super();
closed=false;
}
// Public
public void setConnection(SpyConnection connection)
{
this.connection=connection;
}
public void close() throws Exception
{
closed=true;
}
//One TemporaryDestination has been deleted
public void deleteTemporaryDestination(SpyDestination dest) throws JMSException
{
if (closed) throw new IllegalStateException(The connection is
closed);
connection.deleteTemporaryDestination(dest);
}
public ConnectionReceiver createClient() throws JMSException
{
return this;
}
public void receive(ReceiveRequest messages[]) throws Exception {
if (closed)
throw new IllegalStateException(The connection is closed);
Log.log(ConnectionReceiver: Receive(ReceiveRequest[ +
messages.length +]));
connection.deliver(messages);
}
}
1.1
jbossmq/src/main/org/jbossmq/distributed/server/DistributedJMSServerINVM.java
Index: DistributedJMSServerINVM.java
===
/*
* JBossMQ, the OpenSource JMS implementation
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jbossmq.distributed.server;
import javax.jms.JMSException;
import javax.jms.Destination;
import javax.jms.Topic;
import javax.jms.Queue;
import javax.jms.TemporaryTopic;
import javax.jms.TemporaryQueue;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.RemoteException;
import org.jbossmq.Log;
import org.jbossmq.server.JMSServer;
import org.jbossmq.TransactionRequest;
import org.jbossmq.SpyMessage;
import org.jbossmq.AcknowledgementRequest;
import org.jbossmq.distributed.interfaces.DistributedJMSServerSetup;
import org.jbossmq.SpyDestination;
import org.jbossmq.distributed.interfaces.DistributedJMSServer;
import org.jbossmq.SpyDistributedConnection;
/**
*The RMI implementation of the DistributedJMSServer object
*
*@author Hiram Chirino ([EMAIL PROTECTED])
*@author Norbert Lataille ([EMAIL PROTECTED])
*
*@version $Revision: 1.1 $
*/
public class DistributedJMSServerINVM implements DistributedJMSServer,
DistributedJMSServerSetup, DistributedJMSServerINVMMBean {
// Attributes
//The server implementation
private JMSServer server;
// Constructor ---
Re: [JBoss-dev] JMS thread usage
Well, there's nothing like being embarsed to get my lazy but workin. I've allready commited some several changes that should reduce the number of thread being wasted by JBossMQ. The change will have eliminated all the 38 threads here: -- 38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99) It should also significantly reduce the number of threads at : -- 122: org.jbossmq.Mutex.waitLock And I have a feeling that I just took care of these too. There is a new INVM IL (invocation layer) that get stored in JNDI using the NonSerializable factory. If the ASF stuff is configured to use the connection factorys of the INVM IL, no extra threads will be generated. -- 39: org.jbossmq.distributed.server.DistributedJMSServerOIL.run(DistributedJMSSer verOIL.java:89 -- 38: org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverO IL.java:110) The changes have been commited to the JBossMQ module.. I start working on integrating with the the rest of the jboss modules so we can test to see If what I did really did help. Regards, Hiram - Original Message - From: danch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 10:57 PM Subject: Re: [JBoss-dev] JMS thread usage Chris' nightly test runs have only been failing with these OutOfMemory exceptions for the last couple of nights. Either it was a recent change that caused this or a recently added test that brought it into the open -danch Hiram Chirino wrote: I'm embarased. I'll look into it right away. Since the JMS client and server stuff is running in the same VM when using ASF I should be able to get rid of the socket calls and thus free up the threads that are polling the sockets. I'll also see if I can get rid of the SpySession Threads when using the ASF.. Regards, Hiram - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:04 PM Subject: [JBoss-dev] JMS thread usage I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
User: starksm
Date: 01/06/21 21:09:32
Modified:src/main/org/jboss/metadata Tag: Branch_2_4
ApplicationMetaData.java
Log:
Add an unauthenticatedPrincipal attribute
Revision ChangesPath
No revision
No revision
1.16.4.1 +18 -6 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.16
retrieving revision 1.16.4.1
diff -u -r1.16 -r1.16.4.1
--- ApplicationMetaData.java 2001/06/10 07:46:16 1.16
+++ ApplicationMetaData.java 2001/06/22 04:09:32 1.16.4.1
@@ -20,17 +20,17 @@
import org.jboss.ejb.DeploymentException;
-/**
- * description
+/** The top level meta data from the jboss.xml descriptor.
*
* MessageDriven Bean added
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
- * @author Peter Antman ([EMAIL PROTECTED])
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.16 $
+ * @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
+ * @version $Revision: 1.16.4.1 $
*/
-public class ApplicationMetaData extends MetaData {
+public class ApplicationMetaData extends MetaData
+{
// Constants -
// Attributes
@@ -41,7 +41,10 @@
private HashMap configurations = new HashMap();
private HashMap resources = new HashMap();
private HashMap plugins = new HashMap();
+/** The security-domain value assigned to the application */
private String securityDomain;
+/** The unauthenticated-principal value assigned to the application */
+private String unauthenticatedPrincipal;
private boolean enforceEjbRestrictions;
// Static
@@ -99,6 +102,10 @@
{
return securityDomain;
}
+public String getUnauthenticatedPrincipal()
+{
+return unauthenticatedPrincipal;
+}
public boolean getEnforceEjbRestrictions()
{
return enforceEjbRestrictions;
@@ -306,6 +313,11 @@
Element securityDomainElement = getOptionalChild(element, security-domain);
if( securityDomainElement != null )
securityDomain = getElementContent(securityDomainElement);
+
+ // Get the unauthenticated-principal name
+ Element unauth = getOptionalChild(element, unauthenticated-principal);
+ if( unauth != null )
+ unauthenticatedPrincipal = getElementContent(unauth);
// find the container configurations (we need them first to use them in the
beans)
Element confs = getOptionalChild(element, container-configurations);
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EnterpriseContext.java
User: starksm
Date: 01/06/21 21:10:22
Modified:src/main/org/jboss/ejb Tag: Branch_2_4
EnterpriseContext.java
Log:
Update getCallerPrincipal() to check for a getUnauthenticatedPrincipal()
value in the absence of a caller principal and a security domain
Revision ChangesPath
No revision
No revision
1.31.2.1 +35 -16jboss/src/main/org/jboss/ejb/EnterpriseContext.java
Index: EnterpriseContext.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EnterpriseContext.java,v
retrieving revision 1.31
retrieving revision 1.31.2.1
diff -u -r1.31 -r1.31.2.1
--- EnterpriseContext.java2001/06/12 20:09:01 1.31
+++ EnterpriseContext.java2001/06/22 04:10:22 1.31.2.1
@@ -29,7 +29,9 @@
import javax.transaction.HeuristicRollbackException;
import org.jboss.logging.Logger;
+import org.jboss.metadata.ApplicationMetaData;
import org.jboss.metadata.SecurityRoleRefMetaData;
+import org.jboss.security.RealmMapping;
import org.jboss.security.SimplePrincipal;
/**
@@ -42,7 +44,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
- * @version $Revision: 1.31 $
+ * @version $Revision: 1.31.2.1 $
*/
public abstract class EnterpriseContext
{
@@ -62,10 +64,10 @@
Transaction transaction;
// The principal associated with the call
- Principal principal;
+ private Principal principal;
// The principal for the bean associated with the call
- Principal beanPrincipal;
+ private Principal beanPrincipal;
// Only StatelessSession beans have no Id, stateful and entity do
Object id;
@@ -188,21 +190,38 @@
throw new EJBException(Deprecated);
}
- public Principal getCallerPrincipal()
- {
- if (beanPrincipal == null principal != null)
+ /** Get the Principal for the current caller. This method
+cannot return null according to the ejb-spec.
+ */
+ public Principal getCallerPrincipal()
+ {
+ if( beanPrincipal == null )
+ {
+ RealmMapping rm = con.getRealmMapping();
+ if( principal != null )
{
- if( con.getRealmMapping() == null ) {
- beanPrincipal = principal;
- } else {
- beanPrincipal = con.getRealmMapping().getPrincipal(principal);
- }
+if( rm != null )
+ beanPrincipal = rm.getPrincipal(principal);
+else
+ beanPrincipal = principal;
}
- else if( beanPrincipal == null con.getRealmMapping() == null )
- throw new IllegalStateException(No security context set);
- return beanPrincipal;
- }
-
+ else if( rm != null )
+ { // Let the RealmMapping map the null principal
+beanPrincipal = rm.getPrincipal(principal);
+ }
+ else
+ { // Check for a unauthenticated principal value
+ApplicationMetaData appMetaData =
con.getBeanMetaData().getApplicationMetaData();
+String name = appMetaData.getUnauthenticatedPrincipal();
+if( name != null )
+ beanPrincipal = new SimplePrincipal(name);
+ }
+ }
+ if( beanPrincipal == null )
+ throw new IllegalStateException(No security context set);
+ return beanPrincipal;
+ }
+
public EJBHome getEJBHome()
{
if (con instanceof EntityContainer)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/security/test TestEJBSpec.java
User: starksm
Date: 01/06/21 21:31:43
Modified:src/main/org/jboss/test/security/test TestEJBSpec.java
Log:
Add test of the unauthenticated-principal tag
Revision ChangesPath
1.6 +4 -3 jbosstest/src/main/org/jboss/test/security/test/TestEJBSpec.java
Index: TestEJBSpec.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/security/test/TestEJBSpec.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestEJBSpec.java 2001/06/15 08:48:25 1.5
+++ TestEJBSpec.java 2001/06/22 04:31:43 1.6
@@ -15,7 +15,7 @@
deployment unit. These test the basic role based access model.
@author [EMAIL PROTECTED]
-@version $Revision: 1.5 $
+@version $Revision: 1.6 $
*/
public class TestEJBSpec extends junit.framework.TestCase
{
@@ -46,6 +46,7 @@
public void testGetCallerPrincipal() throws Exception
{
logout();
+System.out.println(+++ testGetCallerPrincipal());
InitialContext jndiContext = new InitialContext();
Object obj = jndiContext.lookup(spec.UnsecureStatelessSession2);
obj = PortableRemoteObject.narrow(obj, StatelessSessionHome.class);
@@ -57,12 +58,12 @@
try
{
// This should fail because echo calls getCallerPrincipal()
-bean.echo(Hello);
+bean.echo(Hello from nobody?);
fail(Was able to call StatelessSession.echo);
}
catch(RemoteException e)
{
-System.out.println(echo failed);
+System.out.println(echo failed as expected);
}
bean.remove();
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/security/META-INF jboss-spec.xml
User: starksm Date: 01/06/21 21:31:43 Modified:src/resources/security/META-INF jboss-spec.xml Log: Add test of the unauthenticated-principal tag Revision ChangesPath 1.6 +9 -0 jbosstest/src/resources/security/META-INF/jboss-spec.xml Index: jboss-spec.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/security/META-INF/jboss-spec.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jboss-spec.xml2001/06/15 08:48:25 1.5 +++ jboss-spec.xml2001/06/22 04:31:43 1.6 @@ -5,10 +5,19 @@ descriptor so that there is no conflict with the security.jar deployment. -- jboss + unauthenticated-principalnobody/unauthenticated-principal + container-configurations !-- StatelessSession beans are secure by default -- container-configuration container-nameStandard Stateless SessionBean/container-name +role-mapping-managerjava:/jaas/spec-test/role-mapping-manager +authentication-modulejava:/jaas/spec-test/authentication-module +/container-configuration + +!-- Entity beans are secure by default -- +container-configuration +container-nameStandard BMP EntityBean/container-name role-mapping-managerjava:/jaas/spec-test/role-mapping-manager authentication-modulejava:/jaas/spec-test/authentication-module /container-configuration ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build run_tests.xml
User: starksm
Date: 01/06/21 21:31:43
Modified:src/build run_tests.xml
Log:
Add test of the unauthenticated-principal tag
Revision ChangesPath
1.15 +2 -1 jbosstest/src/build/run_tests.xml
Index: run_tests.xml
===
RCS file: /cvsroot/jboss/jbosstest/src/build/run_tests.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- run_tests.xml 2001/06/19 02:48:53 1.14
+++ run_tests.xml 2001/06/22 04:31:43 1.15
@@ -2,7 +2,7 @@
!-- An ant build file for running the test code against a
JBoss server dist
-$Revision: 1.14 $
+$Revision: 1.15 $
--
project name=JBossUnitTests default=run-tests basedir=../../
@@ -311,6 +311,7 @@
classpath
path refid=test.classpath /
+pathelement path=${build.classes.dir} /
pathelement path=${jboss.lib}/jboss-jaas.jar /
/classpath
formatter type=plain usefile=false /
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problems with your website
Hello, Could you please check that the file /business/main.css is not missing. I can get the main index Bye Lau Eng Huat ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-435343 ] Merged non-null patch (424409)
Change Notes item #435343, was updated on 2001-06-21 22:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435343group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: Merged non-null patch (424409) Initial Comment: Merged patch to add a 'nullable' attribute to jaws metadata for CMP fields. thanks to David Jencks -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435343group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCInitCommand.java
User: danch
Date: 01/06/21 22:04:23
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCInitCommand.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name of a primary key field caused the primary key
constraint to be wrong
Revision ChangesPath
1.35 +36 -35jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- JDBCCommand.java 2001/06/22 03:24:49 1.34
+++ JDBCCommand.java 2001/06/22 05:04:23 1.35
@@ -58,10 +58,11 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Revision: 1.34 $
+ * @version $Revision: 1.35 $
*
* Revision:
* 20010621 danch: add getter for name
+ * 20010621 (ref 1.25) danch: improve logging: an exception execing SQL is an error!
*/
public abstract class JDBCCommand
{
@@ -164,11 +165,11 @@
{
log.debug(name + command executing: + theSQL);
}
- stmt = con.prepareStatement(theSQL);
- setParameters(stmt, argOrArgs);
- result = executeStatementAndHandleResult(stmt,
argOrArgs);
+ stmt = con.prepareStatement(theSQL);
+ setParameters(stmt, argOrArgs);
+ result = executeStatementAndHandleResult(stmt, argOrArgs);
} catch(SQLException e) {
- log.debug(e);
+ log.error(Exception caught executing SQL: +e);
throw e;
} finally
{
@@ -458,12 +459,12 @@
// Use the class loader to deserialize
try {
- ObjectInputStream ois = new ObjectInputStream(bais);
+ObjectInputStream ois = new ObjectInputStream(bais);
- result = ((MarshalledObject) ois.readObject()).get();
+result = ((MarshalledObject) ois.readObject()).get();
- // ejb-reference: get the object back from the handle
- if (result instanceof Handle) result =
((Handle)result).getEJBObject();
+// ejb-reference: get the object back from the handle
+if (result instanceof Handle) result = ((Handle)result).getEJBObject();
// is this a marshalled object that we stuck in earlier?
if (result instanceof MarshalledObject
!destination.equals(MarshalledObject.class))
@@ -491,8 +492,8 @@
}
ois.close();
- } catch (RemoteException e) {
- throw new SQLException(Unable to load EJBObject back
from Handle: +e);
+ } catch (RemoteException e) {
+throw new SQLException(Unable to load EJBObject back from Handle:
+e);
} catch (IOException e) {
throw new SQLException(Unable to load a ResultSet column +idx+
into a variable of type '+destination.getName()+': +e);
} catch (ClassNotFoundException e) {
@@ -503,20 +504,20 @@
return result;
}
- /**
- * Wrapper around getResultObject(ResultSet rs, int idx, Class destination).
- */
- protected Object getResultObject(ResultSet rs, int idx, CMPFieldMetaData
cmpField)
- throws SQLException {
- if (!cmpField.isNested()) {
- // do it as before
- return getResultObject(rs, idx, cmpField.getField().getType());
- }
-
- // Assuming no one will ever use BLOPS in composite objects.
- // TODO Should be tested for BLOPability
- return rs.getObject(idx);
- }
+ /**
+* Wrapper around getResultObject(ResultSet rs, int idx, Class destination).
+*/
+ protected Object getResultObject(ResultSet rs, int idx, CMPFieldMetaData
cmpField)
+ throws SQLException {
+ if (!cmpField.isNested()) {
+ // do it as before
+ return getResultObject(rs, idx, cmpField.getField().getType());
+ }
+
+ // Assuming no one will ever use BLOPS in composite objects.
+ // TODO Should be tested for BLOPability
+ return rs.getObject(idx);
+ }
/**
@@ -646,7 +647,7 @@
protected Object getCMPFieldValue(Object instance, CMPFieldMetaData
fieldMetaData)
throws
[JBoss-dev] [ jboss-Change Notes-435344 ] fix bug with PK field != column name
Change Notes item #435344, was updated on 2001-06-21 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435344group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug with PK field != column name Initial Comment: Fixed a bug where the PK constraint was generated incorrectly when a PK field was mapped to a column of a different name. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435344group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java
User: danch
Date: 01/06/21 22:04:24
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
CMPFieldMetaData.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name of a primary key field caused the primary key
constraint to be wrong
Revision ChangesPath
1.7 +309 -283
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CMPFieldMetaData.java 2001/05/03 12:36:03 1.6
+++ CMPFieldMetaData.java 2001/06/22 05:04:24 1.7
@@ -31,230 +31,249 @@
*
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
- * @version $Revision: 1.6 $
+ * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
+ * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
+ * @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
+ * @version $Revision: 1.7 $
+ *
+ * Revison:
+ * 20010621 danch: merged patch from David Jenks - null constraint on columns.
*/
public class CMPFieldMetaData extends MetaData implements XmlLoadable {
- // Constants -
+ // Constants -
- // Attributes
+ // Attributes
- // the entity this field belongs to
- private JawsEntityMetaData jawsEntity;
+ // the entity this field belongs to
+ private JawsEntityMetaData jawsEntity;
- // name of the field
+ // name of the field
private String name;
- // the actual Field in the bean implementation
- private Field field;
+ // the actual Field in the bean implementation
+ private Field field;
- // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
- private int jdbcType;
- // true if jdbcType has been initialized
- private boolean validJdbcType;
+ // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
+ private int jdbcType;
+ // true if jdbcType has been initialized
+ private boolean validJdbcType;
+
+ // the sql type, used for table creation.
+ private String sqlType;
+
+ // the column name in the table
+ private String columnName;
+
+ // for table creation, whether to include not null constraint on column
+ private boolean nullable = true;
+
+ private boolean isAPrimaryKeyField;
+
+
+ /**
+* We need this for nested field retrieval.
+*/
+ private String ejbClassName;
+
+ /**
+* We need this for nested fields. We could compute it from ejbClassName on the
fly,
+* but it's faster to set it once and cache it.
+*/
+ private Class ejbClass;
+
+ /**
+* Is true for fields like data.categoryPK.
+*/
+ private boolean isNested;
+
+ // Static
+
+ // Constructors --
+ public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws
DeploymentException {
+ this.name = name;
+ this.jawsEntity = jawsEntity;
+
+ // save the class name for nested fields
+ ejbClassName = jawsEntity.getEntity().getEjbClass();
+ ejbClassName = jawsEntity.getEntity().getEjbClass();
+
+ try {
+ // save the class for nested fields
+ ejbClass =
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
+ field = ejbClass.getField(name);
+ } catch (ClassNotFoundException e) {
+ throw new DeploymentException(ejb class not found: + ejbClassName);
+ } catch (NoSuchFieldException e) {
+ // we can't throw an Exception here, because we could have a nested field
+ checkField();
+ }
- // the sql type, used for table creation.
- private String sqlType;
+ // default, may be overridden by importXml
+ columnName = getLastComponent(name);
- // the column name in the table
- private String columnName;
+ // cannot set defaults for jdbctype/sqltype, type mappings are not loaded yet.
+ }
- private boolean isAPrimaryKeyField;
+ // Public
+ public String getName() { return name
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml jbossmq.xml
User: chirino Date: 01/06/21 22:24:31 Modified:src/etc/conf/default jboss.jcml jbossmq.xml Log: Updated JBoss with the latest JBossMQ which includes fixes for the recent threading issues. I have alos updated the JMProviderLoader so that the references to the connection factory locations can be set via JMX. The jboss.jcml file was updated so that MDBs uese the INVM IL for better performance. Revision ChangesPath 1.41 +2 -0 jboss/src/etc/conf/default/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- jboss.jcml2001/06/16 05:51:24 1.40 +++ jboss.jcml2001/06/22 05:24:31 1.41 @@ -169,6 +169,8 @@ mbean code=org.jboss.jms.jndi.JMSProviderLoader name=:service=JMSProviderLoader,name=JBossMQProvider attribute name=ProviderNameDefaultJMSProvider/attribute attribute name=ProviderAdapterClassorg.jboss.jms.jndi.JBossMQProvider/attribute +attribute name=QueueFactoryRefINVMXAQueueConnectionFactory/attribute +attribute name=TopicFactoryRefINVMXATopicConnectionFactory/attribute /mbean mbean code=org.jboss.jms.asf.ServerSessionPoolLoader name=:service=ServerSessionPoolMBean,name=StdJMSPool attribute name=PoolNameStdJMSPool/attribute 1.6 +10 -0 jboss/src/etc/conf/default/jbossmq.xml Index: jbossmq.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jbossmq.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jbossmq.xml 2001/05/22 09:23:24 1.5 +++ jbossmq.xml 2001/06/22 05:24:31 1.6 @@ -65,6 +65,16 @@ ReceiverClassorg.jbossmq.distributed.server.ConnectionReceiverRMIImpl/ReceiverClass ServerClassorg.jbossmq.distributed.server.DistributedJMSServerRMIImpl/ServerClass /InvocationLayer + InvocationLayer + NameINVM/Name + TopicConnectionFactoryJNDIINVMTopicConnectionFactory/TopicConnectionFactoryJNDI + QueueConnectionFactoryJNDIINVMQueueConnectionFactory/QueueConnectionFactoryJNDI + XATopicConnectionFactoryJNDIINVMXATopicConnectionFactory/XATopicConnectionFactoryJNDI + XAQueueConnectionFactoryJNDIINVMXAQueueConnectionFactory/XAQueueConnectionFactoryJNDI + ReceiverClassorg.jbossmq.distributed.server.ConnectionReceiverINVM/ReceiverClass + ServerClassorg.jbossmq.distributed.server.DistributedJMSServerINVM/ServerClass + /InvocationLayer + /Server ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: chirino
Date: 01/06/21 22:24:32
Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java
Log:
Updated JBoss with the latest JBossMQ which includes fixes for the
recent threading issues. I have alos updated the JMProviderLoader
so that the references to the connection factory locations can be
set via JMX. The jboss.jcml file was updated so that MDBs uese the
INVM IL for better performance.
Revision ChangesPath
1.3 +3 -3 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java
Index: JmsManagedConnection.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JmsManagedConnection.java 2001/06/18 20:01:26 1.2
+++ JmsManagedConnection.java 2001/06/22 05:24:31 1.3
@@ -102,7 +102,7 @@
* Created: Tue Apr 10 13:09:45 2001
*
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class JmsManagedConnection implements ManagedConnection{
@@ -396,7 +396,7 @@
// Get connectionFactory
TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.
- lookup(adapter.getTopicFactoryName());
+ lookup(adapter.getTopicFactoryRef());
// Set up connection
if(user != null)
@@ -415,7 +415,7 @@
// Get connectionFactory
QueueConnectionFactory queueFactory =
(QueueConnectionFactory)context.
- lookup(adapter.getQueueFactoryName());
+ lookup(adapter.getQueueFactoryRef());
// Queue connection
if (user != null)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client jbossmq-client.jar
User: chirino Date: 01/06/21 22:24:31 Modified:src/client jbossmq-client.jar Log: Updated JBoss with the latest JBossMQ which includes fixes for the recent threading issues. I have alos updated the JMProviderLoader so that the references to the connection factory locations can be set via JMX. The jboss.jcml file was updated so that MDBs uese the INVM IL for better performance. Revision ChangesPath 1.7 +230 -223 jboss/src/client/jbossmq-client.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbossmq.jar
User: chirino Date: 01/06/21 22:24:31 Modified:src/lib jbossmq.jar Log: Updated JBoss with the latest JBossMQ which includes fixes for the recent threading issues. I have alos updated the JMProviderLoader so that the references to the connection factory locations can be set via JMX. The jboss.jcml file was updated so that MDBs uese the INVM IL for better performance. Revision ChangesPath 1.9 +335 -295 jboss/src/lib/jbossmq.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
User: chirino
Date: 01/06/21 22:24:31
Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Log:
Updated JBoss with the latest JBossMQ which includes fixes for the
recent threading issues. I have alos updated the JMProviderLoader
so that the references to the connection factory locations can be
set via JMX. The jboss.jcml file was updated so that MDBs uese the
INVM IL for better performance.
Revision ChangesPath
1.15 +3 -3
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
Index: JMSContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JMSContainerInvoker.java 2001/06/21 00:25:54 1.14
+++ JMSContainerInvoker.java 2001/06/22 05:24:31 1.15
@@ -58,7 +58,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class JMSContainerInvoker implements
ContainerInvoker, XmlLoadable
@@ -233,7 +233,7 @@
// All classes are different between topics and queues!!
TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.
-lookup(adapter.getTopicFactoryName());
+lookup(adapter.getTopicFactoryRef());
// Do we have a user - this is messy code (should be done for queues to)
TopicConnection topicConnection;
if(user != null)
@@ -307,7 +307,7 @@
{
Logger.debug(Got destination type Queue);
QueueConnectionFactory queueFactory =
-
(QueueConnectionFactory)context.lookup(adapter.getQueueFactoryName());
+
(QueueConnectionFactory)context.lookup(adapter.getQueueFactoryRef());
// Do we have a user
QueueConnection queueConnection;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/jndi AbstractJMSProviderAdapter.java JBossMQProvider.java JMSProviderAdapter.java JMSProviderLoader.java JMSProviderLoaderMBean.java JBossLocalTXProvider.java
User: chirino
Date: 01/06/21 22:24:31
Modified:src/main/org/jboss/jms/jndi AbstractJMSProviderAdapter.java
JBossMQProvider.java JMSProviderAdapter.java
JMSProviderLoader.java JMSProviderLoaderMBean.java
Removed: src/main/org/jboss/jms/jndi JBossLocalTXProvider.java
Log:
Updated JBoss with the latest JBossMQ which includes fixes for the
recent threading issues. I have alos updated the JMProviderLoader
so that the references to the connection factory locations can be
set via JMX. The jboss.jcml file was updated so that MDBs uese the
INVM IL for better performance.
Revision ChangesPath
1.4 +83 -61
jboss/src/main/org/jboss/jms/jndi/AbstractJMSProviderAdapter.java
Index: AbstractJMSProviderAdapter.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jms/jndi/AbstractJMSProviderAdapter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractJMSProviderAdapter.java 2001/06/18 20:01:25 1.3
+++ AbstractJMSProviderAdapter.java 2001/06/22 05:24:31 1.4
@@ -25,91 +25,113 @@
* provide connection names via instance initialzation and provide an
* implementaion of {@link #getInitialContext}.
*
- * @version pre$Revision: 1.3 $/pre
+ * 6/22/01 - hchirino - The queue/topic jndi references are now configed via JMX
+ *
+ * @version pre$Revision: 1.4 $/pre
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
+ * @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
*/
-public abstract class AbstractJMSProviderAdapter
+public class AbstractJMSProviderAdapter
implements JMSProviderAdapter, java.io.Serializable
{
- /** The queue factory name to use. */
- protected String queueFactoryName;
- /** The topic factory name to use. */
- protected String topicFactoryName;
+
+
/** The name of the provider. */
protected String name;
/** The provider url. */
protected String providerURL;
- /**
-* Initialize.
-*
-* @param queueFactoryNameThe name of the queue factory to use.
-* @param topicFactoryNameThe name of the topic factory to use.
-*/
- protected AbstractJMSProviderAdapter(final String queueFactoryName,
-final String topicFactoryName)
- {
- this.queueFactoryName = queueFactoryName;
- System.out.println(queue factory name: + this.queueFactoryName);
- this.topicFactoryName = topicFactoryName;
- System.out.println(topic factory name: + this.topicFactoryName);
- }
+
/**
-* Set the name of the provider.
-*
-* @param nameThe provider name.
-*/
+ * Set the name of the provider.
+ *
+ * @param nameThe provider name.
+ */
public void setName(final String name) {
- this.name = name;
- }
+ this.name = name;
+ }
/**
-* Get the name of the provider.
-*
-* @return The provider name.
-*/
+ * Get the name of the provider.
+ *
+ * @return The provider name.
+ */
public final String getName() {
- return name;
- }
+ return name;
+ }
/**
-* Set the URL that will be used to connect to the JNDI provider.
-*
-* @param url The URL that will be used to connect.
-*/
+ * Set the URL that will be used to connect to the JNDI provider.
+ *
+ * @param url The URL that will be used to connect.
+ */
public void setProviderUrl(final String url) {
- this.providerURL = url;
- }
+ this.providerURL = url;
+ }
/**
-* Get the URL that is currently being used to connect to the JNDI
-* provider.
-*
-* @return The URL that is currently being used.
-*/
+ * Get the URL that is currently being used to connect to the JNDI
+ * provider.
+ *
+ * @return The URL that is currently being used.
+ */
public final String getProviderUrl() {
- return providerURL;
- }
+ return providerURL;
+ }
- /**
-* Get the JNDI name of the queue factory connection to use.
-*
-* @return JNDI name of the queue factory connection to use.
-*/
- public final String getQueueFactoryName() {
- return queueFactoryName;
- }
- /**
-* Get the JNDI name of the topic factory connection to use.
-*
-* @return JNDI name of the topic factory connection to use.
-*/
- public final String getTopicFactoryName() {
- return topicFactoryName;
- }
+
+
+
+ /** The queue factory name to use. */
+ protected String queueFactoryRef;
+ /** The topic factory name to use.
Re: [JBoss-dev] JMS thread usage
I have updated jboss to to include the latest fixes that I have just maked to jbossqm for those threading issues. Could you update the jars in the jbosstest module and test again and let me know if the situation improved? Regards, Hiram - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:04 PM Subject: [JBoss-dev] JMS thread usage I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. Here is the breakdown of the top active threads in terms of the thread_count: last jboss code in the thread stack JMS ASF Threads: 29: org.jboss.jms.asf.ThreadPool$Slot.waitWhileEmpty(ThreadPool.java:181) SpySession Threads: 122: org.jbossmq.Mutex.waitLock DistributedJMSServerOIL Threads: 39: org.jbossmq.distributed.server.DistributedJMSServerOIL.run(DistributedJMSSer verOIL.java:89) SpyConnection Thread: 38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99) ConnectionReceiverOIL Server 38: org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverO IL.java:110) Passivator Threads: 24: org.jboss.util.WorkerQueue.getJobImpl HyperSonic: 11: org.hsql.ServerConnection.run ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat/security JBossSecurityMgrRealm.java
User: starksm
Date: 01/06/21 22:37:52
Modified:tomcat/src/main/org/jboss/tomcat/security
JBossSecurityMgrRealm.java
Log:
Merged changes from the 2.2 branch
Revision ChangesPath
1.4 +28 -29
contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java
Index: JBossSecurityMgrRealm.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JBossSecurityMgrRealm.java2001/06/12 20:02:31 1.3
+++ JBossSecurityMgrRealm.java2001/06/22 05:37:52 1.4
@@ -9,10 +9,10 @@
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.security.auth.Subject;
-import javax.servlet.http.HttpServletResponse;
import org.apache.log4j.Category;
import org.apache.tomcat.core.BaseInterceptor;
+import org.apache.tomcat.core.TomcatException;
import org.apache.tomcat.core.Request;
import org.apache.tomcat.core.Response;
import org.apache.tomcat.util.SecurityTools;
@@ -37,13 +37,13 @@
@see org.jboss.security.SubjectSecurityManager
@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
+@version $Revision: 1.4 $
*/
public class JBossSecurityMgrRealm extends BaseInterceptor
{
static Category category =
Category.getInstance(JBossSecurityMgrRealm.class.getName());
-public String subjectAttributeName = j_subject;
-public boolean useJAAS = false;
+private String subjectAttributeName = j_subject;
+private boolean useJAAS = false;
/** A flag to indicate if the security manager implements the
SubjectSecurityManager
rather than EJBSecurityManager. When true, the authenticated Subject is
obtained
@@ -62,16 +62,32 @@
this.subjectAttributeName = subjectAttributeName;
}
- public int authenticate(Request request, Response response)
+private Context getSecurityContext()
{
+Context securityCtx = null;
+// Get the JBoss security manager from the ENC context
+try
+{
+InitialContext iniCtx = new InitialContext();
+securityCtx = (Context) iniCtx.lookup(java:comp/env/security);
+}
+catch(NamingException e)
+{
+// Apparently there is no security context?
+}
+return securityCtx;
+}
+
+public int authenticate(Request request, Response response)
+{
/* Get the username credentials from the request. We dont check
that they are null as the security domain may consider this
a valid indication of an unauthenticated user requesting
anonymous access.
*/
- Hashtable credentialMap = new Hashtable();
- SecurityTools.credentials(request, credentialMap);
- String username = (String) credentialMap.get(username);
+Hashtable credentialMap = new Hashtable();
+SecurityTools.credentials(request, credentialMap);
+String username = (String) credentialMap.get(username);
String password = (String) credentialMap.get(password);
// If we don't have a security context security is not required
@@ -144,7 +160,7 @@
String username = request.getRemoteUser();
if( username == null )
-return HttpServletResponse.SC_UNAUTHORIZED;
+return 401;
/* Make sure the thread context class loader it set ot the servlet
class loader. The Jdk12Interceptor should be handling this but
@@ -164,7 +180,6 @@
{
if( scl != cl )
Thread.currentThread().setContextClassLoader(scl);
-
boolean userHasRole = false;
Set requiredRoles = new HashSet(Arrays.asList(roles));
// Get the JBoss security manager from the ENC context
@@ -177,7 +192,7 @@
}
else
{
-category.warn(no security context available);
+category.warn(Warning: no security context available);
}
if( userHasRole )
@@ -190,13 +205,13 @@
else
{
category.debug(User: +username+ is NOT authorized,
requiredRoles=+requiredRoles);
-code = HttpServletResponse.SC_FORBIDDEN;
+code = 401;
}
}
catch(NamingException e)
{
category.error(Error during authorize, e);
-code = HttpServletResponse.SC_UNAUTHORIZED;
+code = 401;
}
finally
{
@@ -205,22 +220,6 @@
}
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
User: danch
Date: 01/06/21 22:41:05
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCInitCommand.java
Log:
fix bug when PK field != columnname
Revision ChangesPath
No revision
No revision
1.12.6.1 +21 -15
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java
Index: JDBCInitCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java,v
retrieving revision 1.12
retrieving revision 1.12.6.1
diff -u -r1.12 -r1.12.6.1
--- JDBCInitCommand.java 2001/01/24 20:36:24 1.12
+++ JDBCInitCommand.java 2001/06/22 05:41:05 1.12.6.1
@@ -30,7 +30,12 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.12 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
+ * @version $Revision: 1.12.6.1 $
+ *
+ * Revision:
+ * 20010621 danch: fixed bug where mapping a PK field to a different column name
+ *resulted in an improper PK constraint.
*/
public class JDBCInitCommand
extends JDBCUpdateCommand
@@ -59,17 +64,18 @@
first = false;
}
- // If there is a primary key field,
- // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
- // add primary key constraint.
- if (jawsEntity.getPrimKeyField() != null jawsEntity.hasPkConstraint()) {
- sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
- for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
- sql += ((PkFieldMetaData)i.next()).getName();
- sql += i.hasNext()?,:;
- }
- sql +=);
+ // If there is a primary key field,
+ // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
+ // add primary key constraint.
+ if (jawsEntity.getPrimKeyField() != null jawsEntity.hasPkConstraint()) {
+ sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
+ for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
+String keyCol = ((PkFieldMetaData)i.next()).getColumnName();
+sql += keyCol;
+sql += i.hasNext()?,:;
}
+ sql +=);
+ }
sql += );
@@ -122,10 +128,10 @@
jdbcExecute(null);
factory.getContainer().getTransactionManager().commit ();
- // Create successful, log this
- log.log(Created table '+jawsEntity.getTableName()+'
successfully.);
- log.debug(Primary key of table '+jawsEntity.getTableName()+'
is '
- +jawsEntity.getPrimKeyField()+'.);
+// Create successful, log this
+log.log(Created table '+jawsEntity.getTableName()+'
successfully.);
+log.debug(Primary key of table '+jawsEntity.getTableName()+' is
'
+ +jawsEntity.getPrimKeyField()+'.);
} catch (Exception e)
{
log.debug(Could not create table +
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-435348 ] fix bug when PK field != column name
Change Notes item #435348, was updated on 2001-06-21 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435348group_id=22866 Category: None Group: v2.4 Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug when PK field != column name Initial Comment: Fixed a bug where the PK constraint was generated incorrectly when a PK field was mapped to a column of a different name. This has already been fixed on MAIN. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=435348group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat jboss.conf.patch jboss.jcml.patch server.xml.patch
User: starksm Date: 01/06/21 22:49:08 Modified:tomcat/src/etc/conf/tomcat jboss.conf.patch jboss.jcml.patch server.xml.patch Log: Merge the 2.2 branch changes Revision ChangesPath 1.2 +8 -10 contrib/tomcat/src/etc/conf/tomcat/jboss.conf.patch Index: jboss.conf.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/jboss.conf.patch,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss.conf.patch 2001/04/18 02:40:41 1.1 +++ jboss.conf.patch 2001/06/22 05:49:08 1.2 @@ -1,11 +1,10 @@ -*** ../default/jboss.confTue Apr 17 13:28:07 2001 jboss.conf Tue Apr 17 13:30:03 2001 +*** jboss.conf Thu May 24 10:10:07 2001 +--- jboss.conf.tomcatThu May 24 10:14:12 2001 *** -*** 41,52 - /MLET +*** 42,52 -! !-- Uncomment to add Tomcat classes to classpath + !-- Uncomment to add Tomcat classes to classpath ! -- MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ! -- ARG TYPE=java.lang.String VALUE=path to tomcat /lib goes here ! -- ARG TYPE=java.lang.String VALUE=Tomcat @@ -14,14 +13,13 @@ !-- Uncomment to add Jetty classes to classpath (make sure Arg1 ends in a slash) -- MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ 41,51 - /MLET +--- 42,51 -! !-- Uncomment to add Tomcat classes to classpath-- + !-- Uncomment to add Tomcat classes to classpath ! MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ -! ARG TYPE=java.lang.String VALUE=../../../tomcat/lib/ -! ARG TYPE=java.lang.String VALUE=Tomcat +! ARG TYPE=java.lang.String VALUE=../../../tomcat/lib/ +! ARG TYPE=java.lang.String VALUE=Tomcat ! /MLET !-- Uncomment to add Jetty classes to classpath (make sure Arg1 ends in a slash) 1.2 +4 -4 contrib/tomcat/src/etc/conf/tomcat/jboss.jcml.patch Index: jboss.jcml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/jboss.jcml.patch,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss.jcml.patch 2001/04/18 02:40:41 1.1 +++ jboss.jcml.patch 2001/06/22 05:49:08 1.2 @@ -1,12 +1,12 @@ -*** ../default/jboss.jcmlTue Apr 17 13:34:28 2001 jboss.jcml Tue Apr 17 13:37:50 2001 +*** jboss.jcml Thu May 24 10:18:58 2001 +--- jboss.jcml.tomcatThu May 24 10:18:15 2001 *** *** 116,124 attribute name=BeanCacheJMSMonitoringEnabledfalse/attribute /mbean ! !-- Uncomment to add embedded tomcat service -mbean code=org.jboss.tomcat.EmbeddedTomcatService name=DefaultDomain:service=EmbeddedTomcat / +mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / --- !-- Uncomment and set file URL to add Jetty service (you can set config more than once) @@ -16,7 +16,7 @@ /mbean ! !-- Uncomment to add embedded tomcat service -- -mbean code=org.jboss.tomcat.EmbeddedTomcatService name=DefaultDomain:service=EmbeddedTomcat / +mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / !-- Uncomment and set file URL to add Jetty service (you can set config more than once) mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jetty 1.4 +63 -23contrib/tomcat/src/etc/conf/tomcat/server.xml.patch Index: server.xml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/server.xml.patch,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- server.xml.patch 2001/04/18 20:19:33 1.3 +++ server.xml.patch 2001/06/22 05:49:08 1.4 @@ -1,8 +1,12 @@ *** server.xml Tue Dec 12 13:36:20 2000 server.jboss.xml Wed Apr 18 13:21:15 2001 +--- server.jboss.xml Thu May 24 09:52:03 2001 *** -*** 124,135 +*** 120,135 ContextInterceptor + className=org.apache.tomcat.context.LoaderInterceptor / + ContextInterceptor + className=org.apache.tomcat.context.DefaultCMSetter / + ContextInterceptor className=org.apache.tomcat.context.WorkDirInterceptor / ! !-- Request processing -- @@ -14,18 +18,16 @@ RequestInterceptor className=org.apache.tomcat.request.SessionInterceptor noCookies=false / 124,146 +--- 120,140 +
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml
User: starksm Date: 01/06/21 23:06:52 Modified:src/etc/conf/default jboss.jcml Log: Make org.jboss.tomcat.EmbeddedTomcatServiceSX the default DefaultDomain:service=EmbeddedTomcat Revision ChangesPath 1.42 +1 -1 jboss/src/etc/conf/default/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- jboss.jcml2001/06/22 05:24:31 1.41 +++ jboss.jcml2001/06/22 06:06:52 1.42 @@ -155,7 +155,7 @@ /mbean !-- Uncomment to add embedded tomcat service - mbean code=org.jboss.tomcat.EmbeddedTomcatService name=DefaultDomain:service=EmbeddedTomcat / + mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / -- !-- Uncomment and set file URL to add Jetty service (you can set config more than once) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
