[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/16 18:46:43
Modified:src/main/org/jboss/verifier/strategy Tag: Branch_3_0
EJBVerifier20.java
Log:
Fixed bug #543693 where verifier didn't look into super classes for
various methods.
Revision ChangesPath
No revision
No revision
1.17.2.1 +5 -5 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.17
retrieving revision 1.17.2.1
diff -u -r1.17 -r1.17.2.1
--- EJBVerifier20.java14 Apr 2002 12:00:07 - 1.17
+++ EJBVerifier20.java17 Apr 2002 01:46:43 - 1.17.2.1
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.17 2002/04/14 12:00:07 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.17.2.1 2002/04/17 01:46:43 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.17.2.1 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -1965,7 +1965,7 @@
fieldName.substring(1);
Class fieldType = null;
try {
- Method m = bean.getDeclaredMethod(getName, new
Class[0]);
+ Method m = bean.getMethod(getName, new Class[0]);
fieldType = m.getReturnType();
} catch (NoSuchMethodException nsme) {
fireSpecViolationEvent(entity, new Section(10.6.2.g));
@@ -1976,11 +1976,11 @@
Class[] args = new Class[1];
args[0] = fieldType;
try {
- Method m = bean.getDeclaredMethod(setName, args);
+ Method m = bean.getMethod(setName, args);
} catch (NoSuchMethodException nsme) {
args[0] = classloader.loadClass(java.util.Collection);
try {
- Method m = bean.getDeclaredMethod(setName,
args);
+ Method m = bean.getMethod(setName, args);
} catch (NoSuchMethodException nsme2) {
fireSpecViolationEvent(entity, new Section(10.6.2.h));
status = false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/14 05:00:08
Modified:src/main/org/jboss/verifier/strategy EJBVerifier20.java
Log:
Removed bit of debugging code
Revision ChangesPath
1.17 +2 -3 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- EJBVerifier20.java14 Apr 2002 01:12:05 - 1.16
+++ EJBVerifier20.java14 Apr 2002 12:00:07 - 1.17
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.16 2002/04/14 01:12:05 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.17 2002/04/14 12:00:07 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -1398,7 +1398,6 @@
}
if (entity.isCMP() hasMatchingEJBFind(bean, method)) {
-System.out.println(Method is +method.getName());
fireSpecViolationEvent(entity, method, new
Section(10.6.2.j));
status = false;
} else if (entity.isBMP()) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/13 18:12:05
Modified:src/main/org/jboss/verifier/strategy EJBVerifier20.java
Log:
Entity bean verification is working a bit better, it's now all turned on.
Revision ChangesPath
1.16 +99 -63jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- EJBVerifier20.java12 Apr 2002 03:38:32 - 1.15
+++ EJBVerifier20.java14 Apr 2002 01:12:05 - 1.16
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.15 2002/04/12 03:38:32 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.16 2002/04/14 01:12:05 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.15 $
+ * @version $Revision: 1.16 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -119,16 +119,14 @@
remoteHomeVerified = verifyEntityHome(entity);
localHomeVerified = verifyEntityLocalHome(entity);
-System.out.println(WARNING: EJBVerifier2.0 Entity Bean verification not
complete);
-if (entity != null) return;
+remoteVerified = verifyEntityRemote(entity);
+localVerified = verifyEntityLocal(entity);
+pkVerified = verifyPrimaryKey(entity);
if (entity.isCMP())
beanVerified = verifyCMPEntityBean(entity);
else if (entity.isBMP())
beanVerified = verifyBMPEntityBean(entity);
-remoteVerified = verifyEntityRemote(entity);
-localVerified = verifyEntityLocal(entity);
-pkVerified = verifyPrimaryKey(entity);
/*
* The entity bean MUST implement either a remote home and remote, or
@@ -1400,7 +1398,8 @@
}
if (entity.isCMP() hasMatchingEJBFind(bean, method)) {
-fireSpecViolationEvent(entity, method, new
Section(10.6.2.h));
+System.out.println(Method is +method.getName());
+fireSpecViolationEvent(entity, method, new
Section(10.6.2.j));
status = false;
} else if (entity.isBMP()) {
if (!hasMatchingEJBFind(bean, method)) {
@@ -1960,39 +1959,35 @@
* Spec 10.6.2
*/
- /*try { This isn't quite working right yet,so I'll leave it
off
-it = entity.getCMPFields();
-while(it.hasNext()) {
-String fieldName = (String)it.next();
- String getName = get +
fieldName.substring(0,1).toUpperCase() +
- fieldName.substring(1);
-try {
- Method m = bean.getDeclaredMethod(getName, new
Class[0]);
- } catch (NoSuchMethodException nsme) {
-fireSpecViolationEvent(entity, new Section(10.6.2.g));
-status = false;
- }
- String setName = set +
fieldName.substring(0,1).toUpperCase() +
- fieldName.substring(1);
-Field field = bean.getField(fieldName);
-Class[] args = new Class[1];
- args[0] = field.getType();
+it = entity.getCMPFields();
+while(it.hasNext()) {
+String fieldName = (String)it.next();
+ String getName = get +
fieldName.substring(0,1).toUpperCase() +
+ fieldName.substring(1);
+ Class fieldType = null;
+try {
+ Method m = bean.getDeclaredMethod(getName, new
Class[0]);
+ fieldType = m.getReturnType();
+ } catch (NoSuchMethodException nsme) {
+fireSpecViolationEvent(entity, new Section(10.6.2.g));
+status = false;
+ }
+ String setName = set +
fieldName.substring(0,1).toUpperCase() +
+ fieldName.substring(1);
+Class[] args = new Class[1
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/verifier DefaultMessages.properties
User: jwalters Date: 02/04/13 18:12:05 Modified:src/resources/org/jboss/verifier DefaultMessages.properties Log: Entity bean verification is working a bit better, it's now all turned on. Revision ChangesPath 1.14 +2 -4 jboss/src/resources/org/jboss/verifier/DefaultMessages.properties Index: DefaultMessages.properties === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/verifier/DefaultMessages.properties,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- DefaultMessages.properties12 Apr 2002 03:38:34 - 1.13 +++ DefaultMessages.properties14 Apr 2002 01:12:05 - 1.14 @@ -157,10 +157,10 @@ 10.6.2.b = The entity bean class must be defined as public and abstract. 10.6.2.c = The entity bean class must define a public constructor that takes no arguments. 10.6.2.d = The entity bean class must not define the finalize() method. -10.6.2.i = The entity bean class must not defined ejbFind methods. 10.6.2.g = The entity bean class must define a get accessor for each CMP field. 10.6.2.h = The entity bean class must define a set accessor for each CMP field. -10.6.2.j = The entity bean class must define a get and set accessor for each CMP field. +10.6.2.i = CMP entity beans may not define the implementation of a finder. +10.6.2.j = CMP entity beans may not define the implementation of a finder. 10.6.4.b = The ejbCreate(...) method of an entity bean class must be declared as public. 10.6.4.c = The ejbcreate(...) method of an entity bean class must not be declared as final or static. @@ -197,7 +197,6 @@ 12.2.9.h = The throws clause of a create(...) method must include the javax.ejb.CreateException. 12.2.9.j = The return type for a findMETHOD method must be the entity bean's local interface type (single-object finder) or a collection thereof (for a multi-object finder). 12.2.9.m = The throws clause of a finder method must include the javax.ejb.FinderException. -10.6.2.h = CMP entity beans may not define the implementation of a finder. 12.2.9.i = Each finder method must match one of the ejbFindMETHOD methods defined in the entity bean class. 12.2.9.l = All the exceptions defined in the throws clause of an ejbFind method of the entity bean class must be included in the throws clause of the matching find method of the home interface. 12.2.9.m = Each home method must match a method defined in the entity bean class. @@ -211,7 +210,6 @@ 12.2.11.h = The throws clause of a create(...) method must include the javax.ejb.CreateException. 12.2.11.j = The return type for a findMETHOD method must be the entity bean's local interface type (single-object finder) or a collection thereof (for a multi-object finder). 12.2.11.m = The throws clause of a finder method must include the javax.ejb.FinderException. -10.6.2.h = CMP entity beans may not define the implementation of a finder. 12.2.11.i = Each finder method must match one of the ejbFindMETHOD methods defined in the entity bean class. 12.2.11.l = All the exceptions defined in the throws clause of an ejbFind method of the entity bean class must be included in the throws clause of the matching find method of the home interface. 12.2.11.m = Each local home method must match a method defined in the entity bean class. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/11 03:17:42
Modified:src/main/org/jboss/verifier/strategy EJBVerifier20.java
Log:
Turned off entity bean verification until it gets cleaned up a bit more.
Revision ChangesPath
1.14 +4 -2 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- EJBVerifier20.java9 Apr 2002 04:27:25 - 1.13
+++ EJBVerifier20.java11 Apr 2002 10:17:42 - 1.14
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.13 2002/04/09 04:27:25 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.14 2002/04/11 10:17:42 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -110,6 +110,8 @@
public void checkEntity(EntityMetaData entity)
{
boolean pkVerified = false;
+System.out.println(WARNING: EJBVerifier2.0 Entity Bean verification not
implemented);
+if (!pkVerified) return;
boolean beanVerified = false;
boolean remoteHomeVerified = false;
boolean remoteVerified = false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/11 20:38:34
Modified:src/main/org/jboss/verifier/strategy EJBVerifier20.java
Log:
Entity home and local home interface are now working, rest of
entity verification is still commented out pending some test.
Revision ChangesPath
1.15 +201 -238 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- EJBVerifier20.java11 Apr 2002 10:17:42 - 1.14
+++ EJBVerifier20.java12 Apr 2002 03:38:32 - 1.15
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.14 2002/04/11 10:17:42 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.15 2002/04/12 03:38:32 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -110,8 +110,6 @@
public void checkEntity(EntityMetaData entity)
{
boolean pkVerified = false;
-System.out.println(WARNING: EJBVerifier2.0 Entity Bean verification not
implemented);
-if (!pkVerified) return;
boolean beanVerified = false;
boolean remoteHomeVerified = false;
boolean remoteVerified = false;
@@ -119,13 +117,16 @@
boolean localVerified = false;
boolean localOrHomeExists = true;
+remoteHomeVerified = verifyEntityHome(entity);
+localHomeVerified = verifyEntityLocalHome(entity);
+System.out.println(WARNING: EJBVerifier2.0 Entity Bean verification not
complete);
+if (entity != null) return;
+
if (entity.isCMP())
beanVerified = verifyCMPEntityBean(entity);
else if (entity.isBMP())
beanVerified = verifyBMPEntityBean(entity);
-remoteHomeVerified = verifyEntityHome(entity);
remoteVerified = verifyEntityRemote(entity);
-localHomeVerified = verifyEntityLocalHome(entity);
localVerified = verifyEntityLocal(entity);
pkVerified = verifyPrimaryKey(entity);
@@ -1090,6 +1091,10 @@
*
* Spec 12.2.9
*/
+
+String beanClass = entity.getEjbClass();
+Class bean= classloader.loadClass(beanClass);
+
methods = Arrays.asList(home.getMethods()).iterator();
while (methods.hasNext()) {
@@ -1100,164 +1105,125 @@
if (method.getDeclaringClass().getName().equals(EJB_HOME_INTERFACE))
continue;
- // No way to figure out if it's a home method at the
moment...
-//if (! (isCreateMethod(method) || isFinderMethod(method) ||
-// isHomeMethod(method)) ) {
-//fireSpecViolationEvent(entity, method, new
Section(12.2.9.c));
-//status = false;
-//}
-}
-
-/*
- * Each create(...) method in the entity bean's home interface MUST
- * have a matching ejbCreate(...) method in the entity bean's class.
- *
- * Each create(...) method in the entity bean's home interface MUST
- * have the same number and types of arguments to its matching
- * ejbCreate(...) method.
- *
- * The return type for a create(...) method MUST be the entity
- * bean's remote interface type.
- *
- * All the exceptions defined in the throws clause of the matching
- * ejbCreate(...) and ejbPostCreate(...) methods of the enterprise
- * bean class MUST be included in the throws clause of a matching
- * create(...) method.
- *
- * The throws clause of a create(...) method MUST include the
- * javax.ejb.CreateException.
- *
- * Spec 12.2.9
- */
-Iterator createMethods = getCreateMethods(home);
-
-try {
-String beanClass = entity.getEjbClass();
-Class bean= classloader.loadClass(beanClass);
-
-while (createMethods.hasNext()) {
-
-Method create = (Method)createMethods.next
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/verifier DefaultMessages.properties
User: jwalters Date: 02/04/11 20:38:34 Modified:src/resources/org/jboss/verifier DefaultMessages.properties Log: Entity home and local home interface are now working, rest of entity verification is still commented out pending some test. Revision ChangesPath 1.13 +29 -0 jboss/src/resources/org/jboss/verifier/DefaultMessages.properties Index: DefaultMessages.properties === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/verifier/DefaultMessages.properties,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- DefaultMessages.properties9 Apr 2002 04:06:38 - 1.12 +++ DefaultMessages.properties12 Apr 2002 03:38:34 - 1.13 @@ -188,4 +188,33 @@ 12.2.1.a = The bean provider must specify the fully-qualified name of the primary key class for the entity bean. + +12.2.9.a = Entity bean's home interface must extend the javax.ejb.EJBHome interface. +12.2.9.b = The methods in the home interface must not include java.rmi.RemoteException in their throws clause. +12.2.9.e = Each create(...) method in the entity bean's home interface must have a matching ejbCreate(...) method in the entity bean's class. +12.2.9.f = The return type for a create(...) method must be the entity bean's local interface type. +12.2.9.g = All the exceptions defined in the throws clause of the matching ejbCreate(...) and ejbPostCreate(...) methods of the enterprise bean class must be included in the throws clause of a matching create(...) method. +12.2.9.h = The throws clause of a create(...) method must include the javax.ejb.CreateException. +12.2.9.j = The return type for a findMETHOD method must be the entity bean's local interface type (single-object finder) or a collection thereof (for a multi-object finder). +12.2.9.m = The throws clause of a finder method must include the javax.ejb.FinderException. +10.6.2.h = CMP entity beans may not define the implementation of a finder. +12.2.9.i = Each finder method must match one of the ejbFindMETHOD methods defined in the entity bean class. +12.2.9.l = All the exceptions defined in the throws clause of an ejbFind method of the entity bean class must be included in the throws clause of the matching find method of the home interface. +12.2.9.m = Each home method must match a method defined in the entity bean class. +12.2.9.n = A home method declared in the home interface must not return the entity beans remote interface. + +12.2.11.a = The Entity bean's local home interface must extend the javax.ejb.EJBLocalHome interface. +12.2.11.b = The methods in the local home interface must not include java.rmi.RemoteException in their throws clause. +12.2.11.e = Each create(...) method in the entity bean's local home interface must have a matching ejbCreate(...) method in the entity bean's class. +12.2.11.f = The return type for a create(...) method must be the entity bean's local interface type. +12.2.11.g = All the exceptions defined in the throws clause of the matching ejbCreate(...) and ejbPostCreate(...) methods of the enterprise bean class must be included in the throws clause of a matching create(...) method. +12.2.11.h = The throws clause of a create(...) method must include the javax.ejb.CreateException. +12.2.11.j = The return type for a findMETHOD method must be the entity bean's local interface type (single-object finder) or a collection thereof (for a multi-object finder). +12.2.11.m = The throws clause of a finder method must include the javax.ejb.FinderException. +10.6.2.h = CMP entity beans may not define the implementation of a finder. +12.2.11.i = Each finder method must match one of the ejbFindMETHOD methods defined in the entity bean class. +12.2.11.l = All the exceptions defined in the throws clause of an ejbFind method of the entity bean class must be included in the throws clause of the matching find method of the home interface. +12.2.11.m = Each local home method must match a method defined in the entity bean class. +12.2.11.n = A home method declared in the local home interface must not return the entity beans remote interface. + 22.2 = The bean provider must specify the fully-qualified name of the Java class that implements the enterprise bean's business methods. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJBDeployer (verifier)
The EJB 2.0 verifier is in process. Next time I work on it I'll try to remove all the code generating spurious messages. Many things have changed between EJB 1.1 and EJB 2.0, and I didn't catch them all in the process of moving the code over. Cheers Dave Smith wrote: I am getting these errors over and over again on all of the EJB's I am deploying 18:58:31,586 INFO [EJBDeployer] Bean : cadex/AcrossResp Method : public abstract EJBMetaData getEJBMetaData() throws RemoteException Section: 12.2.9 Warning: null If the home is extended from EJBHome is this not there? 18:58:31,593 INFO [EJBDeployer] Bean : cadex/AcrossResp Section: 10.8.1 Warning: The primkey-field must be one of the CMP fields of the entity bean. Snip from ejb-jar.xml ejb-namecadex/AcrossResp/ejb-name prim-key-classjava.lang.Long/prim-key-class cmp-field description![CDATA[]]/description field-nameobjectid/field-name /cmp-field primkey-fieldobjectid/primkey-field I did declare cmp-file in jbosscmp-jdbc.xml without the primkey-field it should not be necessary? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/verifier DefaultMessages.properties
User: jwalters Date: 02/04/07 19:35:02 Modified:src/resources/org/jboss/verifier DefaultMessages.properties Log: First pass at EJB 2.0 Verifier. Handles session beans, though not all messages are in the properties file yet. Most entity bean code is in, but not turned on until it can be tested more thoroughly. Revision ChangesPath 1.11 +20 -0 jboss/src/resources/org/jboss/verifier/DefaultMessages.properties Index: DefaultMessages.properties === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/verifier/DefaultMessages.properties,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- DefaultMessages.properties7 Jun 2001 21:23:31 - 1.10 +++ DefaultMessages.properties8 Apr 2002 02:35:02 - 1.11 @@ -110,3 +110,23 @@ 16.5.a = An entity bean requires a primary key class (prim-key-class tag). +7.10.1 = The session bean must implement either a remote home and remote, or a local home and a local interface. + +7.10.2.a = A session bean must implement, directly or indirectly, the SessionBean interface. +7.5.3.a = A stateless Session bean must not implement the SessionSynchronization interface. +7.5.3.b = A session bean using bean-managed transaction demarcation may not implement the SessionSynchronization interface. +7.10.3 = A session bean must implement at least one ejbCreate method. +7.6.1= A bean with bean-managed transaction demarcation cannot implement the SessionSynchronization interface. + +7.10.2.b1 = The session bean class must be defined as public. +7.10.2.b2 = The session bean class must not be final. +7.10.2.b3 = The session bean class must not be abstract. +7.10.2.c = The session bean class must have a public constructor that takes no parameters. +7.10.2.d = The class must not define the finalize() method. + +7.10.3.b = The ejbCreate(...) method of a session bean class must be declared as public. +7.10.3.c = The ejbCreate(...) method of a session bean class must not be declared as final or static. +7.10.3.d = The return type of an ejbCreate(...) method must be void. +7.10.3.e = The method arguments of an ejbCreate(...) method must be legal types for RMI/IIOP. + +22.2 = The bean provider must specify the fully-qualified name of the Java class that implements the enterprise bean's business methods. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/ejbconf/beans/ejb ReadOnlyBean.java
User: jwalters
Date: 02/04/08 21:06:39
Modified:src/main/org/jboss/test/ejbconf/beans/ejb ReadOnlyBean.java
Log:
Updated verifier to do simple entity bean verification for EJB 2.0.
Updated some of the tests so the beans are in compliance with EJB 2.0.
Revision ChangesPath
1.2 +2 -2
jbosstest/src/main/org/jboss/test/ejbconf/beans/ejb/ReadOnlyBean.java
Index: ReadOnlyBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/ejbconf/beans/ejb/ReadOnlyBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ReadOnlyBean.java 30 Jan 2002 23:00:32 - 1.1
+++ ReadOnlyBean.java 9 Apr 2002 04:06:39 - 1.2
@@ -52,14 +52,14 @@
* @return an codeInteger/code value
* @ejb:create-method
*/
- public Integer ejbCreate(Integer id, Integer value)
+ public Integer ejbCreate(Integer id, Integer value) throws CreateException
{
setId(id);
setValue(value);
return null;
}
- public Integer ejbPostCreate(Integer id, Integer value)
+ public void ejbPostCreate(Integer id, Integer value)
{
return null;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/verifier DefaultMessages.properties
User: jwalters Date: 02/04/08 21:06:38 Modified:src/resources/org/jboss/verifier DefaultMessages.properties Log: Updated verifier to do simple entity bean verification for EJB 2.0. Updated some of the tests so the beans are in compliance with EJB 2.0. Revision ChangesPath 1.12 +63 -4 jboss/src/resources/org/jboss/verifier/DefaultMessages.properties Index: DefaultMessages.properties === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/verifier/DefaultMessages.properties,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- DefaultMessages.properties8 Apr 2002 02:35:02 - 1.11 +++ DefaultMessages.properties9 Apr 2002 04:06:38 - 1.12 @@ -110,23 +110,82 @@ 16.5.a = An entity bean requires a primary key class (prim-key-class tag). -7.10.1 = The session bean must implement either a remote home and remote, or a local home and a local interface. - -7.10.2.a = A session bean must implement, directly or indirectly, the SessionBean interface. 7.5.3.a = A stateless Session bean must not implement the SessionSynchronization interface. 7.5.3.b = A session bean using bean-managed transaction demarcation may not implement the SessionSynchronization interface. -7.10.3 = A session bean must implement at least one ejbCreate method. 7.6.1= A bean with bean-managed transaction demarcation cannot implement the SessionSynchronization interface. +7.8.a= The home interface of a stateless session bean must have one create method that takes no arguments. +7.8.b= The create method of a stateless session bean home interface must return the session bean's remote interface. +7.8.c= There can be only one create method in the home interface of a stateless session bean. + +7.10.1 = The session bean must implement either a remote home and remote, or a local home and a local interface. + +7.10.2.a = A session bean must implement, directly or indirectly, the SessionBean interface. 7.10.2.b1 = The session bean class must be defined as public. 7.10.2.b2 = The session bean class must not be final. 7.10.2.b3 = The session bean class must not be abstract. 7.10.2.c = The session bean class must have a public constructor that takes no parameters. 7.10.2.d = The class must not define the finalize() method. +7.10.3 = A session bean must implement at least one ejbCreate method. 7.10.3.b = The ejbCreate(...) method of a session bean class must be declared as public. 7.10.3.c = The ejbCreate(...) method of a session bean class must not be declared as final or static. 7.10.3.d = The return type of an ejbCreate(...) method must be void. 7.10.3.e = The method arguments of an ejbCreate(...) method must be legal types for RMI/IIOP. + +7.10.6.a = A session bean's home interface must extend the javax.ejb.EJBHome interface. +7.10.6.b1 = The method arguments in the home interface must be of valid types for RMI/IIOP. +7.10.6.b2 = The method return values in the home interface must be of valid types for RMI/IIOP. +7.10.6.b3 = The methods in the home interface must include java.rmi.RemoteException in their throws clause. +7.10.6.d1 = A session bean's home interface must define one or more create(...) methods. +7.10.6.d2 = The home interface of a stateless session bean must have one create method that takes no arguments. +7.10.6.e = Each create(...) method in the session bean's home interface must have a matching ejbCreate(...) method in the session bean's class. +7.10.6.f = The return type for a create(...) method must be the session bean's remote interface type. +7.10.6.g = All the exceptions defined in the throws clause of the matching ejbCreate(...) method of the enterprise bean class must be included in the throws clause of a matching create(...) method. +7.10.6.h = The throws clause of a create(...) method must include the javax.ejb.CreateException. + +7.10.8.a= A session bean's local home interface must extend the javax.ejb.EJBLocalHome interface. +7.10.8.b = The methods in the local home interface must not include java.rmi.RemoteException in their throws clause. +7.10.8.d1 = A session bean's local home interface must define one or more create(...) methods. +7.10.8.d2= The local home interface of a stateless session bean must have one create method that takes no arguments. +7.10.8.e = Each create(...) method in the session bean's local home interface must have a matching ejbCreate(...) method in the session bean's class. +7.10.8.f = The return type for a create(...) method must be the session bean's local interface type. +7.10.8.g = All the exceptions defined in the throws clause of the matching ejbCreate(...) method of the enterprise bean class must be
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java EJBVerifier20.java
User: jwalters
Date: 02/04/08 21:06:38
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
EJBVerifier20.java
Log:
Updated verifier to do simple entity bean verification for EJB 2.0.
Updated some of the tests so the beans are in compliance with EJB 2.0.
Revision ChangesPath
1.29 +12 -5 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- AbstractVerifier.java 8 Apr 2002 02:35:01 - 1.28
+++ AbstractVerifier.java 9 Apr 2002 04:06:37 - 1.29
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.28 2002/04/08 02:35:01 jwalters Exp $
+ * $Id: AbstractVerifier.java,v 1.29 2002/04/09 04:06:37 jwalters Exp $
*/
// standard imports
@@ -84,7 +84,7 @@
* /ul
* /p
*
- * @version $Revision: 1.28 $
+ * @version $Revision: 1.29 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -322,6 +322,13 @@
}
/*
+ * checks if the given method is declared as abstract
+ */
+public boolean isAbstract(Method m) {
+return (Modifier.isAbstract(m.getModifiers()));
+}
+
+/*
* checks if finder returns the primary key type
*/
public boolean isSingleObjectFinder(EntityMetaData entity, Method finder) {
@@ -1145,11 +1152,11 @@
protected final static String CREATE_METHOD =
create;
-protected final static String HOME_METHOD =
-home;
-
protected final static String EJB_HOME_METHOD =
ejbHome;
+
+protected final static String EJB_SELECT_METHOD =
+ejbSelect;
private final static String FINALIZE_METHOD =
finalize;
1.12 +256 -104 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- EJBVerifier20.java8 Apr 2002 02:35:01 - 1.11
+++ EJBVerifier20.java9 Apr 2002 04:06:37 - 1.12
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.11 2002/04/08 02:35:01 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.12 2002/04/09 04:06:37 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -109,9 +109,8 @@
public void checkEntity(EntityMetaData entity)
{
- System.out.println(WARNING: EJBVerifier2.0 Entity Bean verification not
implemented);
- /* boolean pkVerified = false;
-boolean beanVerified = false; // Need to change this once the code is in
place
+boolean pkVerified = false;
+boolean beanVerified = false;
boolean remoteHomeVerified = false;
boolean remoteVerified = false;
boolean localHomeVerified = false;
@@ -134,7 +133,7 @@
* local home or local interface.
*
* Spec 12.2.1
- *
+ */
if (!(remoteHomeVerified remoteVerified)
!(localHomeVerified localVerified)) {
localOrHomeExists = false;
@@ -145,9 +144,9 @@
/*
* Verification for this entity bean done. Fire the event
* to tell listeneres everything is ok.
- *
+ */
fireBeanVerifiedEvent(entity);
-}*/
+}
}
public void checkMessageBean(BeanMetaData bean)
@@ -165,9 +164,22 @@
return m.getName().startsWith(EJB_CREATE_METHOD);
}
-public boolean isHomeMethod(Method m)
-{
-return m.getName().startsWith(HOME_METHOD);
+ public boolean isEjbSelectMethod(Method m)
+ {
+ return m.getName().startsWith(EJB_SELECT_METHOD);
+ }
+
+public Iterator getEjbSelectMethods(Class c) {
+
+List selects
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/ejbselect ABean.java BBean.java
User: jwalters
Date: 02/04/08 21:06:38
Modified:src/main/org/jboss/test/cmp2/ejbselect ABean.java BBean.java
Log:
Updated verifier to do simple entity bean verification for EJB 2.0.
Updated some of the tests so the beans are in compliance with EJB 2.0.
Revision ChangesPath
1.3 +4 -1 jbosstest/src/main/org/jboss/test/cmp2/ejbselect/ABean.java
Index: ABean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/ejbselect/ABean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ABean.java28 Jan 2002 21:47:10 - 1.2
+++ ABean.java9 Apr 2002 04:06:38 - 1.3
@@ -1,5 +1,6 @@
package org.jboss.test.cmp2.ejbselect;
+import javax.ejb.CreateException;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import javax.ejb.FinderException;
@@ -9,7 +10,9 @@
public abstract class ABean implements EntityBean {
private EntityContext ctx;
- public String ejbCreate(String id) {
+ public ABean() {}
+
+ public String ejbCreate(String id) throws CreateException {
setId(id);
return null;
}
1.3 +4 -1 jbosstest/src/main/org/jboss/test/cmp2/ejbselect/BBean.java
Index: BBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/ejbselect/BBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BBean.java16 Jan 2002 00:05:04 - 1.2
+++ BBean.java9 Apr 2002 04:06:38 - 1.3
@@ -1,12 +1,15 @@
package org.jboss.test.cmp2.ejbselect;
+import javax.ejb.CreateException;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import java.rmi.RemoteException;
public abstract class BBean implements EntityBean {
-public String ejbCreate(String id, String name) {
+public BBean() {}
+
+public String ejbCreate(String id, String name) throws CreateException {
setId(id);
setName(name);
return null;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/readonly BookBean.java PublisherBean.java
User: jwalters
Date: 02/04/08 21:06:38
Modified:src/main/org/jboss/test/cmp2/readonly BookBean.java
PublisherBean.java
Log:
Updated verifier to do simple entity bean verification for EJB 2.0.
Updated some of the tests so the beans are in compliance with EJB 2.0.
Revision ChangesPath
1.2 +3 -1 jbosstest/src/main/org/jboss/test/cmp2/readonly/BookBean.java
Index: BookBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/readonly/BookBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BookBean.java 12 Dec 2001 20:06:38 - 1.1
+++ BookBean.java 9 Apr 2002 04:06:38 - 1.2
@@ -6,7 +6,9 @@
public abstract class BookBean implements EntityBean {
transient private EntityContext ctx;
- public Integer ejbCreate(Integer id) {
+public BookBean() {}
+
+ public Integer ejbCreate(Integer id) throws CreateException {
setId(id);
return null;
}
1.2 +3 -1
jbosstest/src/main/org/jboss/test/cmp2/readonly/PublisherBean.java
Index: PublisherBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/readonly/PublisherBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PublisherBean.java12 Dec 2001 20:06:38 - 1.1
+++ PublisherBean.java9 Apr 2002 04:06:38 - 1.2
@@ -7,7 +7,9 @@
public abstract class PublisherBean implements EntityBean {
transient private EntityContext ctx;
- public Integer ejbCreate(Integer id) {
+public PublisherBean() {}
+
+ public Integer ejbCreate(Integer id) throws CreateException {
setId(id);
return null;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/08 21:27:25
Modified:src/main/org/jboss/verifier/strategy EJBVerifier20.java
Log:
Managed to checkin and break the testsuite... runs properly on my machine now.
Revision ChangesPath
1.13 +11 -6 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- EJBVerifier20.java9 Apr 2002 04:06:37 - 1.12
+++ EJBVerifier20.java9 Apr 2002 04:27:25 - 1.13
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.12 2002/04/09 04:06:37 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.13 2002/04/09 04:27:25 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -1995,7 +1995,7 @@
* Spec 10.6.2
*/
- try {
+ /*try { This isn't quite working right yet,so I'll leave it
off
it = entity.getCMPFields();
while(it.hasNext()) {
String fieldName = (String)it.next();
@@ -2015,14 +2015,19 @@
try {
Method m = bean.getDeclaredMethod(setName,
args);
} catch (NoSuchMethodException nsme) {
-fireSpecViolationEvent(entity, new Section(10.6.2.h));
-status = false;
+args[0] = classloader.loadClass(java.util.Collection);
+try {
+ Method m = bean.getDeclaredMethod(setName,
args);
+} catch (NoSuchMethodException nsme2) {
+fireSpecViolationEvent(entity, new Section(10.6.2.h));
+status = false;
+}
}
}
} catch (NoSuchFieldException nsfe) {
fireSpecViolationEvent(entity, new Section(10.6.2.j));
status = false;
- }
+ }*/
/*
* The ejbSelect(...) method signatures MUST follow these rules:
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/readonly BookBean.java PublisherBean.java
User: jwalters Date: 02/04/08 21:27:25 Modified:src/main/org/jboss/test/cmp2/readonly BookBean.java PublisherBean.java Log: Managed to checkin and break the testsuite... runs properly on my machine now. Revision ChangesPath 1.3 +1 -0 jbosstest/src/main/org/jboss/test/cmp2/readonly/BookBean.java Index: BookBean.java === RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/readonly/BookBean.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- BookBean.java 9 Apr 2002 04:06:38 - 1.2 +++ BookBean.java 9 Apr 2002 04:27:25 - 1.3 @@ -1,5 +1,6 @@ package org.jboss.test.cmp2.readonly; +import javax.ejb.CreateException; import javax.ejb.EntityBean; import javax.ejb.EntityContext; 1.3 +1 -0 jbosstest/src/main/org/jboss/test/cmp2/readonly/PublisherBean.java Index: PublisherBean.java === RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/cmp2/readonly/PublisherBean.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- PublisherBean.java9 Apr 2002 04:06:38 - 1.2 +++ PublisherBean.java9 Apr 2002 04:27:25 - 1.3 @@ -1,6 +1,7 @@ package org.jboss.test.cmp2.readonly; import java.util.Collection; +import javax.ejb.CreateException; import javax.ejb.EntityBean; import javax.ejb.EntityContext; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNP Implementation question
Sorry to post this to dev, but what is the RMI port listed under the Naming MBean? Does JBoss have an RMI registry? We are trying to deploy some simple RMI objects as MBeans for management purposes and we're wondering if we can avoid the use of JNDI or not? Are there any issues with using JMX notifications for application events, for example if we build a MBean which is providing some type of realtime feed service and propagating events along to other MBeans using the notifications is that a bad thing? Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EJB 2.0 Verifier
Is anybody working on this? It seems to just be stubs in the head right now. Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb StatelessSessionContainer.java
User: jwalters
Date: 02/03/12 21:13:20
Modified:src/main/org/jboss/ejb StatelessSessionContainer.java
Log:
Added patch 520631 which puts the missing method into the exception message.
Revision ChangesPath
1.34 +26 -2 jboss/src/main/org/jboss/ejb/StatelessSessionContainer.java
Index: StatelessSessionContainer.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/StatelessSessionContainer.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- StatelessSessionContainer.java15 Feb 2002 00:17:28 - 1.33
+++ StatelessSessionContainer.java13 Mar 2002 05:13:19 - 1.34
@@ -32,7 +32,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Daniel OConnor/a
-* @version $Revision: 1.33 $
+* @version $Revision: 1.34 $
* pb2001219 marc fleury/b
* ul
* li move to the new invocation layer and Invocation object
@@ -477,7 +477,13 @@
if (!m[i].getDeclaringClass().getName().equals(declaringClass))
{
// Implemented by bean
-map.put(m[i], beanClass.getMethod(m[i].getName(),
m[i].getParameterTypes()));
+try {
+ map.put(m[i], beanClass.getMethod(m[i].getName(),
m[i].getParameterTypes()));
+}
+catch (NoSuchMethodException ex)
+{
+ throw new NoSuchMethodException(Method not found in bean class: +
formatMethod(m[i]));
+}
if (debug)
log.debug(Mapped +m[i].getName()+ +m[i].hashCode()+to
+map.get(m[i]));
}
@@ -667,4 +673,22 @@
{
}
}
+
+ private StringBuffer formatMethod(Method method)
+ {
+ StringBuffer buffer = new StringBuffer();
+ buffer.append(method.getName()).append(();
+ Class[] paramTypes = method.getParameterTypes();
+ for (int count = 0; count paramTypes.length; count++) {
+ if (count 0) {
+buffer.append(,);
+ }
+ buffer.
+
append(paramTypes[count].getName().substring(paramTypes[count].getName().lastIndexOf(.)+1));
+ }
+ buffer.append());
+
+ return buffer;
+ }
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtonetbeansdebug.xml
User: jwalters Date: 02/02/04 19:30:14 Modified:src/xdocs/howto howtonetbeansdebug.xml Log: Updated to JBoss 2.4 (somehow previous update was lost). Revision ChangesPath 3.2 +30 -28manual/src/xdocs/howto/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtonetbeansdebug.xml,v retrieving revision 3.1 retrieving revision 3.2 diff -u -r3.1 -r3.2 --- howtonetbeansdebug.xml2001/12/08 03:54:46 3.1 +++ howtonetbeansdebug.xml2002/02/05 03:30:14 3.2 @@ -24,15 +24,17 @@ titleInstall the JBoss Server/title para For the purpose of this howto, I installed the JBossTomcat release version -2.2.2 into d:\JBoss-2.2.2_Tomcat-3.2.2. Download it from -http://www.jboss.org and select the binary link from the page. Don't worry -about downloading a binary package, when all you want is the source code; -the binary package also contains the source code used for building. +2.4.4/3.2.3 into /opt/appserver on my linux box. If you translate the steps +into Windows NT/2000 you can also debug JBoss apps using Netbeans there. +Download it from http://www.jboss.org and select the binary link from the +page. Don't worry about downloading a binary package, when all you want is +the source code; the binary package also contains the source code used for +building. /para /section section titleCreate a NetBeans Project/title -paraStart NetBeans, I used NetBeans 3.2 while writing this howto. The first +paraStart NetBeans, I used NetBeans 3.3 while writing this howto. The first step is to create a new project or open an existing project. You create a new project from the Project -gt; Project Manager menu selection. This dialog will show a list of your projects like: @@ -48,14 +50,14 @@ project you should go to the explorer window and select the FileSystems tab. Either right click on the FileSystems entry in the explorer window, or choose File -gt; Mount Filesystem and pick mount jar. Use the browser or type in the -path for the following jar files: jboss/lib/jdbc2_0-stdext.jar and -jboss/lib/ext/ejb.jar. If you use bean managed transactions you will need to -add jboss/lib/ext/jta-spec1_0_1.jar. If you are using JBossSX security then -you'll also need to add additional jar files jboss/lib/jaas.jar, jboss/lib/jboss-jaas.jar and jboss/lib/ext/jbosssx.jar. If you are using JMS from your -client you'll also need to add jboss/lib/ext/jms.jar and -jboss/lib/ext/jbossmq-client.jar. Once you have -added all these jar files if you don't want them to show in the explorer you can -right click on them one by one and from the properties panel select hidden=true. +path for the following jar files: jboss/lib/ext/jboss-j2ee.jar and +jboss/lib/jboss-jdbc_ext.jar. If you are using JBossSX security then you'll +also need to add additional jar files jboss/lib/jaas.jar, +jboss/lib/jboss-jaas.jar and jboss/lib/ext/jbosssx.jar. +If you are using JMS from your client you'll also need to add +jboss/lib/ext/jbossmq-client.jar. Once you have added all these jar files a +if you don't want them to show in the explorer you can right click on them +one by one and from the properties panel select hidden=true. /para para At this point you need to add any other jar files specific to your app which @@ -140,14 +142,6 @@ /imageobject/mediaobject /section section -titleSprinkle breakpoints throughout your EJB and or Client Code/title -para -First it is necessary to put breakpoints in your ejb's. As outlined -previously project settings should point to the source of your beans. Open -up a typical bean implementation and place breakpoints whereever desired. -/para -/section -section titleStart the JBoss server/title para Start JBoss using the debug script which you previously created. Deploy the @@ -158,12 +152,18 @@ /para /section section -titleDeploy the Beans/title +titleSprinkle breakpoints throughout your EJB and or Client Code/title para -Copy or drag/drop (for windoze fans) the ejb jar file containing the -ejb-jar.xml and jboss.xml (optional) to the deploy folder. If you have set -breakpoints in stateless session ejb's these should cause the debugger to -stop in your code! Hurrah! +Before you can debug, it is necessary to put breakpoints into your code. On +the client side you can just open up your source files and toggle breakpoints +as in any other Netbeans debugging effort. To put breakpoins into your ejb's +is different. You will need to use the loaded classes menus to select the +class and method you would like to break on. Once you have hit a break point +within the class, and the source code is displayed, then you can add +additional breakpoints. This seems to
[JBoss-dev] CVS update: manual/src/xdocs/howto howtonetbeansdebug.xml
User: jwalters Date: 01/12/07 19:54:47 Modified:src/xdocs/howto howtonetbeansdebug.xml Log: Updated email address Revision ChangesPath 3.1 +1 -1 manual/src/xdocs/howto/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtonetbeansdebug.xml,v retrieving revision 3.0 retrieving revision 3.1 diff -u -r3.0 -r3.1 --- howtonetbeansdebug.xml2001/11/18 20:10:58 3.0 +++ howtonetbeansdebug.xml2001/12/08 03:54:46 3.1 @@ -6,7 +6,7 @@ firstnameJay/firstname surnameWalters/surname /author - email[EMAIL PROTECTED]/email + email[EMAIL PROTECTED]/email /para section titlePurpose/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtonetbeansdebug.xml
User: jwalters Date: 01/12/07 20:02:52 Modified:src/xdocs/howto Tag: Branch_2_4 howtonetbeansdebug.xml Log: Updated email address Revision ChangesPath No revision No revision 2.0.4.1 +1 -1 manual/src/xdocs/howto/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtonetbeansdebug.xml,v retrieving revision 2.0 retrieving revision 2.0.4.1 diff -u -r2.0 -r2.0.4.1 --- howtonetbeansdebug.xml2001/11/18 19:14:34 2.0 +++ howtonetbeansdebug.xml2001/12/08 04:02:52 2.0.4.1 @@ -6,7 +6,7 @@ firstnameJay/firstname surnameWalters/surname /author - email[EMAIL PROTECTED]/email + email[EMAIL PROTECTED]/email /para section titlePurpose/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
Definitely a much simpler idea to just build the new stack and replace the old one atomically than to try and build a database for the MBeans. Cheers -Original Message- From: Rickard Öberg To: [EMAIL PROTECTED] Sent: 10/2/01 12:33 PM Subject: Re: [JBoss-dev] JMX service architecture: next gen++ David Jencks wrote: I would like this best if the jmx server state were transactional with versioning optimistic concurrency control, like the firebird/interbase db. In this kind of scheme, an invocation to a mbean would get a jmx transactional view of all the mbeans in the jmx server as of the start of the invocation. The view of mbeans would be stable until the invocation finishes. Other concurrent changes to mbean state would use copy on write semantics and be visible (after they were committed) to jmx transactions started after the commit of the jmx modifications. After all uses of a replaced mbean were complete the (now inacessible) old version of the mbean can be garbage collected. Presumably one could also set up externally controlled jmx transactions so several configuration changes could occur atomically within one transaction. I guess I will have to read more of the mbean spec to see if this is consistent with it ;-) This is doable, but the overhead of it would be enormous... I think sticking with immutable interceptor stacks is good enough to start with :-) Optimistic/versioning or not, I think some kind of jmx transaction to make configuration invisible until it all completes will be necessary to make on the fly reconfiguration plausible and not too disruptive. Not necessarily. All you need to do is have duplicate MBeans and then switch from one set to the other in one atomic operation. Still, this is really tricky to get right. How is this much worse than we have now? Now we have standardjboss.xml with a list of interceptors: then we will have this configuration in a endpoint mbean as a list of mbean references, and also mbean configuration for each interceptor individually. You may be right. It could be ok. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 9/26/01 3:20 PM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/ api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] EJB/QL - JBoss extentions
Another problem is getting the ordering right, it is not a simple problem to write the SQL to get the correct next row for every database for arbitrary queries, but for a fixed query in a finder this might not be so much of an obstacle. Also during the intervening time other transactions could change the contents of the list if everything isn't locked down. Of course since most users would not actually want to process 1M rows, returing small pages of 50 at a time is probably pretty reasonable. Much better than returning all 1M if they are just interested in the first 100. Cheers -Original Message- From: Ignacio Coloma To: [EMAIL PROTECTED] Sent: 9/24/01 3:00 PM Subject: RE: [JBoss-dev] EJB/QL - JBoss extentions Dave Smith wrote: Keep the result set open, retieve from the set as necessary, probably using a cursor. That way if someone is doing a search that has 1 million records and after I display the first 10 and the client chooses the 3rd one, we have only created 10 objects. No, no, no! We can't keep the result set open! 1) having open result set and open Connection for each client, we'll end up with too many open connections and too many open result sets (256 open cursors by default in Oracle). 2) How about transaction bounds? Can you keep cursor open after transaction ends? I don't think so. What about making an automatic paging? Think about something LIKE an open cursor. I'll try to be brief. Suppose this query to return 1,000,000 records: SELECT ID, NAME FROM TABLE ORDER BY NAME; Suppose that you make a PagedCollection (configurable from jbosscmp-jdbc.xml) that only get the first 50 records (and you close the resultset). You show them. When someone tries to get the #51 record and so you make another call (possibly in another new Transaction context) SELECT ID, NAME FROM TABLE WHERE ID #the ID of record 50# ORDER BY NAME; And so on. It would be more effective than any solution the programmer could make by hand. Are there Transaction consecuences on this? I could be missing something. My 2c. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool?
Try and download objecteering from the softteam.fr site or else www.objecteering.com. It is very much alive, they have had several releases in the last 8 months that I have been aware of. Cheers -Original Message- From: Ignacio Coloma To: [EMAIL PROTECTED] Sent: 9/21/01 9:23 PM Subject: RE: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? I'm not sure, but ObjectTeering seem to be marked as Obsolete by the CERN. At the same time, they have a download version for Win2K. I feel lost. IMHO Argo and Poseidon are still buggy (but useful in any case, till they fix them :) http://sdt.cern.ch/Objecteering/ http://www.softeam.fr/us/pser_telechargement.htm -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Jay Walters Enviado el: viernes, 21 de septiembre de 2001 1:05 Para: '[EMAIL PROTECTED] ' Asunto: RE: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? Objecteering personal edition is another lowend UML modeller I've used for sometime. It only runs on Windoze, and oddly enough 12 years after the WIndows look and feel guidelines it has a very unique UI. It is stableand free however. Argo/UML and Poseidon (from same code base) are both good Java tools. I am not sure if they've worked out the kinks, last summer Argo still had some stability issues. Cheers -Original Message- From: Michel Halde To: [EMAIL PROTECTED] Sent: 9/20/01 5:15 AM Subject: Re: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? About sequence diagrams, ArgoUML is a free tool available at www.argouml.org. The free solution with Together is only valid for 30 days! Michel Halde David Jencks wrote: Thank you! I will add this to the docs, I'll try to find a way to make the mysql-service.xml file available directly, maybe in the examples... I haven't looked into how this is organized recently. There are some uml diagrams in the jca spec, but I don't always find them clear. I will look into finding a little time to make some for our manual. Do you know of a free tool that makes sequence diagrams? I think there's a free Together-j that makes class diagrams... there used to be anyway. Looking forward to postgres!! Thanks again david jencks On 2001.09.20 13:01:22 -0400 Ignacio Coloma wrote: Thanks, David. I still feel more or less lost in the Resource Adapter docs (a little more of clarity in the dark, though). Could you please add any kind of UML diagram to help understanding the architecture? I enclose the service.xml file I have put together for mysql. Some of the params are (more or less) guessed, but it works. I'll start another one for postgres this afternoon (GMT), and post it As Soon As It Works(tm). I'm not sure, but sniffing the code it seems that XA Transactions are supported in JBoss but not yet implemented as XADataSources (if I'm wrong correct me). The file that I'm enclosing use Local Transactions. Regards, Ignacio Coloma. P.S.: Yes, I knew the diff between Enhydra and Hypersonic, but my post almost coincided with the Lutris crisis and made my mind a mess while writing it. Thanks for the point anyway :)) P.S2.: How do I contribute these files to the docs? -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Jencks Enviado el: miércoles, 19 de septiembre de 2001 19:44 Para: [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? The (new) manual chapter explains the config parameters pretty well I think, please let me know if it is unclear. http://www.jboss.org/documentation/HTML/ch03.html Please show what you have so far and contribute it to the manual when it works. Thanks david jencks btw hypersonic != enhydra On 2001.09.19 13:28:37 -0400 Ignacio Coloma wrote: Anyone has the xxx-service.xml for a database that is not enhydra? I have coded one, but doesn't work. It could be a bug but since I'm not 100% sure of the config parameters I don't dare to post it as a bug yet. ?xml version=1.0 encoding=UTF-8? !-- = -- !-- -- !-- foo App DataSource -- !-- -- !-- = -- !-- $Id: foo-mysql-service.xml,v 1.0 2001/09/19 02:48:05 icoloma Exp $ -- server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=TransactionManager/depends classpath archives= mm.mysql-2.0.4-bin.jar, jbosscx.sar/ !-- -- !-- JDBC
[JBoss-dev] Tests and new build suite
Sorry to post this on the list but I can't get to the site to read instructions... First let me say the new build process is very nice (I've avoided it during it's teething pains!) How does one run the test suite? I tried build test in the test directory but they all keep failing with what looks like more of a JUnit/Ant (Or my configuration) problem than anything else - (Or are they all just broken?) [junit] Exception in thread main [junit] TEST org.jboss.test.bmp.test.BmpUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.BmpUnitTestCase [junit] java.lang.NullPointerException [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.endTest(XMLJUnitResultFormatter.java:196) [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.formatError(XMLJUnitResultFormatter.java:230) [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.addError(XMLJUnitResultFormatter.java:225) [junit] at junit.framework.TestResult.addError(TestResult.java:36) [junit] at junit.framework.TestResult.runProtected(TestResult.java:133) [junit] at junit.extensions.TestSetup.run(TestSetup.java:23) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. main(JUnitTestRunner.java:409) I'm running Windows 2K pro with Cygwin, Sun JDK 1.3.0-C, classpath= before running the test. Exact same environment as the compile/build which worked. Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tests and new build suite
It was me. It sure helped to start the server up before I ran the tests the second time! Sorry to post first and troubleshoot second... Cheers -Original Message- From: Jay Walters To: '[EMAIL PROTECTED]' Sent: 9/21/01 10:17 PM Subject: [JBoss-dev] Tests and new build suite Sorry to post this on the list but I can't get to the site to read instructions... First let me say the new build process is very nice (I've avoided it during it's teething pains!) How does one run the test suite? I tried build test in the test directory but they all keep failing with what looks like more of a JUnit/Ant (Or my configuration) problem than anything else - (Or are they all just broken?) [junit] Exception in thread main [junit] TEST org.jboss.test.bmp.test.BmpUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.BmpUnitTestCase [junit] java.lang.NullPointerException [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.endTest(XMLJUnitResultFormatter.java:196) [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.formatError(XMLJUnitResultFormatter.java:230) [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo rmatter.addError(XMLJUnitResultFormatter.java:225) [junit] at junit.framework.TestResult.addError(TestResult.java:36) [junit] at junit.framework.TestResult.runProtected(TestResult.java:133) [junit] at junit.extensions.TestSetup.run(TestSetup.java:23) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. main(JUnitTestRunner.java:409) I'm running Windows 2K pro with Cygwin, Sun JDK 1.3.0-C, classpath= before running the test. Exact same environment as the compile/build which worked. Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool?
Objecteering personal edition is another lowend UML modeller I've used for sometime. It only runs on Windoze, and oddly enough 12 years after the WIndows look and feel guidelines it has a very unique UI. It is stableand free however. Argo/UML and Poseidon (from same code base) are both good Java tools. I am not sure if they've worked out the kinks, last summer Argo still had some stability issues. Cheers -Original Message- From: Michel Halde To: [EMAIL PROTECTED] Sent: 9/20/01 5:15 AM Subject: Re: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? About sequence diagrams, ArgoUML is a free tool available at www.argouml.org. The free solution with Together is only valid for 30 days! Michel Halde David Jencks wrote: Thank you! I will add this to the docs, I'll try to find a way to make the mysql-service.xml file available directly, maybe in the examples... I haven't looked into how this is organized recently. There are some uml diagrams in the jca spec, but I don't always find them clear. I will look into finding a little time to make some for our manual. Do you know of a free tool that makes sequence diagrams? I think there's a free Together-j that makes class diagrams... there used to be anyway. Looking forward to postgres!! Thanks again david jencks On 2001.09.20 13:01:22 -0400 Ignacio Coloma wrote: Thanks, David. I still feel more or less lost in the Resource Adapter docs (a little more of clarity in the dark, though). Could you please add any kind of UML diagram to help understanding the architecture? I enclose the service.xml file I have put together for mysql. Some of the params are (more or less) guessed, but it works. I'll start another one for postgres this afternoon (GMT), and post it As Soon As It Works(tm). I'm not sure, but sniffing the code it seems that XA Transactions are supported in JBoss but not yet implemented as XADataSources (if I'm wrong correct me). The file that I'm enclosing use Local Transactions. Regards, Ignacio Coloma. P.S.: Yes, I knew the diff between Enhydra and Hypersonic, but my post almost coincided with the Lutris crisis and made my mind a mess while writing it. Thanks for the point anyway :)) P.S2.: How do I contribute these files to the docs? -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Jencks Enviado el: miércoles, 19 de septiembre de 2001 19:44 Para: [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] Anyone has tried to make a non-hypersonic connection pool? The (new) manual chapter explains the config parameters pretty well I think, please let me know if it is unclear. http://www.jboss.org/documentation/HTML/ch03.html Please show what you have so far and contribute it to the manual when it works. Thanks david jencks btw hypersonic != enhydra On 2001.09.19 13:28:37 -0400 Ignacio Coloma wrote: Anyone has the xxx-service.xml for a database that is not enhydra? I have coded one, but doesn't work. It could be a bug but since I'm not 100% sure of the config parameters I don't dare to post it as a bug yet. ?xml version=1.0 encoding=UTF-8? !-- = -- !-- -- !-- foo App DataSource -- !-- -- !-- = -- !-- $Id: foo-mysql-service.xml,v 1.0 2001/09/19 02:48:05 icoloma Exp $ -- server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=TransactionManager/depends classpath archives= mm.mysql-2.0.4-bin.jar, jbosscx.sar/ !-- -- !-- JDBC - Initialize the databases -- !-- to ConnectionFactoryLoader -- !-- -- mbean code=org.jboss.resource.ConnectionFactoryLoader name=DefaultDomain:service=ConnectionFactoryLoader,name=fooDS attribute name=ManagedConnectionFactoryPropertiesConnectionURL=jdbc:mysql://loc alhost/foo DriverClass=org.gjt.mm.mysql.Driver UserName=/attribute attribute name=JndiNamefooDS/attribute attribute name=TransactionManagerNamejava:/TransactionManager/attribute attribute name=ResourceAdapterNameMinerva JDBC LocalTransaction ResourceAdapter/attribute attribute name=RARDeployerNameJCA:service=RARDeployer/attribute attribute name=ConnectionManagerFactoryNameMinervaSharedLocalCMFactory/attribu te attribute name=ConnectionManagerProperties# #Wed Aug 15 16:17:29 EDT 2001 InvalidateOnError=false BlockingTimeoutMillis=50 IdleTimeoutMillis=180 MaxSize=10 TimestampUsed=false IdleTimeoutEnabled=false
RE: [JBoss-dev] remote debugging from IDEA
Looks like port 5000 from your command, but check the how-to for debugging jboss with netbeans and there should be some info there on the setup of the jvm... Cheers -Original Message- From: Colin Daly To: [EMAIL PROTECTED] Sent: 8/30/01 8:47 PM Subject: [JBoss-dev] remote debugging from IDEA hi, i'm trying to get remote debugging with IntelliJ IDEA and JBoss 2.4 Beta / Jetty distribution. IDEA says that the remote VM must be run in debug mode with the following settings. -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000 ok. then it asks for the host (localhost) and the port. what is the port number I should use? Colin. ___ 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] JDBC SQL Extensions
Not to be too much in oracle's defense, but their proprietary outer join
syntax is much more concise. I think you will need to do mapping onto the
various vendor's syntax...
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 3:11 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] JDBC SQL Extensions
all JDBC experts,
Is it common for the JDBC drivers to support the SQL Extension functions?
http://java.sun.com/j2se/1.3/docs/guide/jdbc/spec/jdbc-spec.frame11.html
I specifically need the functions: concat, substring, locate, length, abs,
and sqrt.
I'm planing on mapping these to {fn concat('str1', 'str2')} style functions.
If it is not common to support these fuctions I'll write a function map spec
in the xml.
Also, do most vendors support the {oj outer-join} syntax like:
SELECT *
FROM {oj order LEFT OUTER JOIN line_item ON
order.ordernumber=line_item.ordernumber}
I think I need this to support the IS EMPTY operator in queries like:
SELECT OBJECT(o)
FROM Order o
WHERE o.lineItems IS EMPTY
Thanks for any help
-dain
P.S. I just found some docs that say that Oracle drivers do not support any
of these portability features (my words). Does anyone find this
supprising? (I'll keep my feelings on this to my self). Any way, if it is
true, I'll implement this the hard way after I get the easy way working.
___
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] JDBC SQL Extensions
Suppose it depends where you start. As somebody with 14 years of Oracle
experience the {oj} example you gave makes no sense to me, so it is both not
concise nor not understandable.
But lets not make this a pissing contest. I agree with you. I think the
core fact is that for a variety of reasons most database vendors really
don't implement all the standards in such a way that a user can take a
real-world application and just move it from one database to the next.
For that reason, I think you're going to need some mapping from EJB-QL to
the various SQL dialects.
Cheers
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 3:39 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JDBC SQL Extensions
consice does not equal understandable
for example
a?b:c
-dain
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 17, 2001 2:16 PM
Subject: RE: [JBoss-dev] JDBC SQL Extensions
Not to be too much in oracle's defense, but their proprietary outer join
syntax is much more concise. I think you will need to do mapping onto the
various vendor's syntax...
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 3:11 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] JDBC SQL Extensions
all JDBC experts,
Is it common for the JDBC drivers to support the SQL Extension functions?
http://java.sun.com/j2se/1.3/docs/guide/jdbc/spec/jdbc-spec.frame11.html
I specifically need the functions: concat, substring, locate, length, abs,
and sqrt.
I'm planing on mapping these to {fn concat('str1', 'str2')} style
functions.
If it is not common to support these fuctions I'll write a function map
spec
in the xml.
Also, do most vendors support the {oj outer-join} syntax like:
SELECT *
FROM {oj order LEFT OUTER JOIN line_item ON
order.ordernumber=line_item.ordernumber}
I think I need this to support the IS EMPTY operator in queries like:
SELECT OBJECT(o)
FROM Order o
WHERE o.lineItems IS EMPTY
Thanks for any help
-dain
P.S. I just found some docs that say that Oracle drivers do not support
any
of these portability features (my words). Does anyone find this
supprising? (I'll keep my feelings on this to my self). Any way, if it is
true, I'll implement this the hard way after I get the easy way working.
___
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-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] JDBC SQL Extensions
I would think you would want to use the EXISTS operator for the reason you
specified - portability - as well as I believe that vendors often optimize
it somewhat for performance.
Cheers
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 4:32 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JDBC SQL Extensions
Sorry for the confusion. There are two issues here.
==
Issue1: use of the {fn concat(str1, str2)} style functions.
Solution: use fn style functions as default but have override in xml like:
concat-functionCONCAT (?1, ?2)/concat-function
or some thing simmilar.
==
Issue 2: IS EMPTY function. How should I map the following ejb-ql query:
SELECT OBJECT(o)
FROM Order o
WHERE o.lineItems IS EMPTY
Solution A:
SELECT o.ordernumber
FROM Order o
WHERE NOT EXISTS (
SELECT l.pk
FROM Order o, LineItem l
WHERE o.ordernumber = l.ordernumber)
I like this because it does not use an outer join (thanks Dave Smith). Does
it have performance problems?
Solution B:
SELECT o.ordernumber
FROM Order o LEFT OUTER JOIN LineItem l ON o.ordernumber = l.ordernumber
WHERE l.ordernumber IS NULL
This would be a major pain to map to all vendors.
___
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] row vs. table level locking
If you have a foreign key on the field which is in the parent table and you do not have an index on the field in the parent table (naughty naughty) then it will lock the entire parent table whenever it needs to check the referential integrity constraint. The fix is to index all fields which are referenced as foreign keys from another table. Luckily this makes sense as it will make the whole thing faster too (usually). Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 8/11/01 5:00 PM Subject: Re: [JBoss-dev] row vs. table level locking Do you know in Oracle if you have a child table with a compound pk that includes the pk of its parent table, if that would case the parent table to lock on child table updates? Sorry, this is off topic, but I am running into some really, really odd oracle deadlock exceptions when running identical tasks in parallel. --jason On Sat, 11 Aug 2001, danch wrote: Nope. We just let the database do what the database will do. Most modern databases will do row locks at this point (ORacle, DB/2, PostgreSQL 7 or higher, M$ SQL Server 7 or higher) Although if you do enough row locks, it could get escalated to a page or table lock. -danch Jason Dillon wrote: Is there anything JBoss specific that controls whether a row or table lock is acquired when dealing with cmp entities? --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-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: manual/src/docs howtonetbeansdebug.xml
User: jwalters Date: 01/08/06 20:24:34 Modified:src/docs Tag: Branch_2_4 howtonetbeansdebug.xml Log: Updated list of jar files to 2.4 - jboss-j2ee,jboss-jdbc_ext.jar. Revision ChangesPath No revision No revision 1.2.2.1 +3 -5 manual/src/docs/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/docs/howtonetbeansdebug.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- howtonetbeansdebug.xml2001/07/03 16:56:29 1.2 +++ howtonetbeansdebug.xml2001/08/07 03:24:34 1.2.2.1 @@ -48,12 +48,10 @@ project you should go to the explorer window and select the FileSystems tab. Either right click on the FileSystems entry in the explorer window, or choose File -gt; Mount Filesystem and pick mount jar. Use the browser or type in the -path for the following jar files: jboss/lib/jdbc2_0-stdext.jar and -jboss/lib/ext/ejb.jar. If you use bean managed transactions you will need to -add jboss/lib/ext/jta-spec1_0_1.jar. If you are using JBossSX security then +path for the following jar files: jboss/lib/jboss-jdbc_ext.jar and +jboss/lib/ext/jboss-j2ee.jar. If you are using JBossSX security then you'll also need to add additional jar files jboss/lib/jaas.jar, jboss/lib/jboss-jaas.jar and jboss/lib/ext/jbosssx.jar. If you are using JMS from your -client you'll also need to add jboss/lib/ext/jms.jar and -jboss/lib/ext/jbossmq-client.jar. Once you have +client you'll also need to add jboss/lib/ext/jbossmq-client.jar. Once you have added all these jar files if you don't want them to show in the explorer you can right click on them one by one and from the properties panel select hidden=true. /para ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] different versions of jboss-j2ee.jar
Oops - sounds like an oversite on (perhaps my part). These jar files just go too many places and it's all by hand. I'm several days behind in my e-mail has anybody fixed this since it was posted? I think there might also be some issues with the JBossCX versions of the j2ee jar files. Cheers -Original Message- From: Henri Chen To: [EMAIL PROTECTED] Sent: 7/20/01 6:31 AM Subject: [JBoss-dev] different versions of jboss-j2ee.jar Hi! In the lastest jboss 2.4 beta release (JBoss-2.4.0.23_Tomcat_3.2.3) , two versions of jboss-j2ee.jar were put at different directory. One is older without javax.ejb.EJBLocalHome, etc was put in ~/jboss/client; anther one is newer was put in ~/jboss/lib/ext. Is this on purpose? Regards, Henri Chen [EMAIL PROTECTED] ___ 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] J2EE Connector spec
Sorry, should have said started us down the road to pfd2. I did enough to get the j2ee tutorial connector working. I've taken these three patches and I'll apply them to CVS. Thanks for your work... -Original Message- From: Tomasz Skutnik [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 8:08 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] J2EE Connector spec I've submitted 3 patches on SourceForge that finish the job. Your CVS update was not complete (see description in patch no 1). Review and submitt if you please. -- Tomasz Skutnik [EMAIL PROTECTED] ___ 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: jbosscx/src/main/org/jboss/resource RARMetaData.java
User: jwalters
Date: 01/07/18 07:36:05
Modified:src/main/org/jboss/resource RARMetaData.java
Log:
Completed update to pfd2, more changes to DTD.
Thanks to Tomasz Skutnik [EMAIL PROTECTED] for the patches.
Revision ChangesPath
1.6 +3 -3 jbosscx/src/main/org/jboss/resource/RARMetaData.java
Index: RARMetaData.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARMetaData.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RARMetaData.java 2001/07/18 02:53:51 1.5
+++ RARMetaData.java 2001/07/18 14:36:05 1.6
@@ -26,7 +26,7 @@
*
* @see RARDeployer
* @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class RARMetaData
// extends Y
@@ -345,12 +345,12 @@
log.warning(Loading +getElementContent(element).trim());
}
- private void setAuthMechanism(Element element) throws DeploymentException
+ private void setAuthenticationMechanism(Element element) throws
DeploymentException
{
invokeChildren(element);
}
- private void setAuthMechType(Element element) throws DeploymentException
+ private void setAuthenticationMechanismType(Element element) throws
DeploymentException
{
authMechType = getElementContent(element);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/resources/jdbc-rar/META-INF ra.xml
User: jwalters Date: 01/07/18 07:38:23 Modified:src/resources/jdbc-rar/META-INF ra.xml Log: Completed update of jbosscx to Connector 1.0 pfd2 Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches. Revision ChangesPath 1.3 +3 -3 jbosspool/src/resources/jdbc-rar/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jbosspool/src/resources/jdbc-rar/META-INF/ra.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ra.xml2001/07/18 02:52:40 1.2 +++ ra.xml2001/07/18 14:38:23 1.3 @@ -72,10 +72,10 @@ config-property-nameDriver/config-property-name config-property-typejava.lang.String/config-property-type /config-property -auth-mechanism -auth-mech-typebasic-password/auth-mech-type +authentication-mechanism + authentication-mechanism-typeBasicPassword/authentication-mechanism-type credential-interfacejavax.resource.security.PasswordCredential/credential-interface -/auth-mechanism +/authentication-mechanism reauthentication-supportfalse/reauthentication-support /resourceadapter /connector ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms/ra/META-INF ra.xml
User: jwalters Date: 01/07/18 07:40:14 Modified:src/resources/org/jboss/jms/ra/META-INF ra.xml Log: Completed update of jbosscx to Connector 1.0 pfd2 spec. Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches Revision ChangesPath 1.3 +3 -3 jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ra.xml2001/07/18 03:01:52 1.2 +++ ra.xml2001/07/18 14:40:14 1.3 @@ -18,10 +18,10 @@ config-property-typejava.lang.String/config-property-type config-property-valuejava:DefaultJMSProvider/config-property-value /config-property -auth-mechanism -auth-mech-typebasic-password/auth-mech-type +authentication-mechanism + authentication-mechanism-typeBasicPassword/authentication-mechanism-type credential-interfacejavax.resource.security.PasswordCredential/credential-interface -/auth-mechanism +/authentication-mechanism reauthentication-supportfalse/reauthentication-support /resourceadapter /connector ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/deploy jbosspool-jdbc.rar
User: jwalters Date: 01/07/18 07:40:13 Modified:src/etc/deploy jbosspool-jdbc.rar Log: Completed update of jbosscx to Connector 1.0 pfd2 spec. Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches Revision ChangesPath 1.5 +40 -50jboss/src/etc/deploy/jbosspool-jdbc.rar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata connector_1_0.dtd
User: jwalters Date: 01/07/18 07:40:15 Modified:src/resources/org/jboss/metadata connector_1_0.dtd Log: Completed update of jbosscx to Connector 1.0 pfd2 spec. Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches Revision ChangesPath 1.2 +13 -13jboss/src/resources/org/jboss/metadata/connector_1_0.dtd Index: connector_1_0.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/connector_1_0.dtd,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- connector_1_0.dtd 2001/02/02 10:12:48 1.1 +++ connector_1_0.dtd 2001/07/18 14:40:15 1.2 @@ -101,7 +101,7 @@ one or more authentication mechanisms supported and additional required security permissions. -If there is no auth-mechanism specified as part of resource adapter +If there is no authentication-mechanism specified as part of resource adapter element then the resource adapter does not support any standard security authentication mechanisms as part of security contract. The application server ignores the security part of the system @@ -112,22 +112,22 @@ managedconnectionfactory-class, connectionfactory-interface, connectionfactory-impl-class, connection-interface, connection-impl-class, transaction-support, config-property*, -auth-mechanism*, reauthentication-support, security-permission* +authentication-mechanism*, reauthentication-support, security-permission* ) !-- -The element auth-mechanism specifies an authentication mechanism +The element authentication-mechanism specifies an authentication mechanism supported by the resource adapter. Note that this support is for the resource adapter and not for the underlying EIS instance. The optional description specifies any resource adapter specific requirement for the support of security contract and authentication mechanism. -Note that basic-password mech-type should support the -javax.resource.spi.security.PasswordCredential interface. The kerbv5 +Note that BasicPassword mech-type should support the +javax.resource.spi.security.PasswordCredential interface. The Kerbv5 mech-type should support the javax.resource.spi.security.Generic- Credential interface. -- -!ELEMENT auth-mechanism (description?, auth-mech-type, credential-interface) +!ELEMENT authentication-mechanism (description?, authentication-mechanism-type, credential-interface) !-- The element credential-interface specifies the interface that the @@ -145,17 +145,17 @@ !ELEMENT credential-interface (#PCDATA) !-- -The element auth-mech-type specifies type of an authentication +The element authentication-mechanism-type specifies type of an authentication mechanism. The example values are: - auth-mech-typebasic-password/auth-mech-type - auth-mech-typekerbv5/auth-mech-type + authentication-mechanism-typeBasicPassword/authentication-mechanism-type + authentication-mechanism-typeKerbv5/authentication-mechanism-type Any additional security mechanisms are outside the scope of the Connector architecture specification. -- -!ELEMENT auth-mech-type (#PCDATA) +!ELEMENT authentication-mechanism-type (#PCDATA) !-- The element connectionfactory-interface specifies the fully-qualified @@ -250,7 +250,7 @@ The following are the legal values of config-property-type: java.lang.Boolean, java.lang.String, java.lang.Integer, java.lang.Double, java.lang.Byte, java.lang.Short, - java.lang.Long, java.lang.Float + java.lang.Long, java.lang.Float, java.lang.Character Example: config-property-typejava.lang.String/config-property-type -- @@ -437,8 +437,8 @@ standard information into the standard deployment descriptor. -- -!ATTLIST auth-mechanism id ID #IMPLIED -!ATTLIST auth-mech-type id ID #IMPLIED +!ATTLIST authentication-mechanism id ID #IMPLIED +!ATTLIST authentication-mechanism-type id ID #IMPLIED !ATTLIST config-property id ID #IMPLIED !ATTLIST config-property-name id ID #IMPLIED !ATTLIST config-property-value id ID #IMPLIED ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/resource/cci ConnectionFactory.java
User: jwalters Date: 01/07/17 19:05:12 Modified:src/main/javax/resource/cci ConnectionFactory.java Log: Removed methods from ConnectionFactory which were removed in the PFD2 doc. Revision ChangesPath 1.2 +0 -28 jboss-j2ee/src/main/javax/resource/cci/ConnectionFactory.java Index: ConnectionFactory.java === RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/resource/cci/ConnectionFactory.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ConnectionFactory.java2001/04/05 04:20:41 1.1 +++ ConnectionFactory.java2001/07/18 02:05:12 1.2 @@ -52,32 +52,4 @@ * an active connection. */ public ResourceAdapterMetaData getMetaData() throws ResourceException; - -/** - * Sets the log writer for the ConnectionFactory. The ConnectionFactory - * uses this log writer for logging and tracing messages. - */ -public void setLogWriter( PrintWriter out ) throws ResourceException; - -/** - * Gets the log writer for the ConnectionFactory. The ConnectionFactory - * uses this log writer for logging and tracing messages. - */ -public PrintWriter setLogWriter() throws ResourceException; - -/** - * Set the timeout in milliseconds for a connection by the resource - * adapter to the underlying application. A value of zero indicates - * to use any system default timeout, or else no timeout if there is - * no system default. At initial creation the timeout value is 0. - */ -public void setTimeout( int milliseconds ) throws ResourceException; - -/** - * Get the timeout in milliseconds for a connection by the resource - * adapter to the underlying application. A value of zero indicates - * to use any system default timeout, or else no timeout if there is - * no system default. - */ -public int getTimeout() throws ResourceException; } ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/lib jboss-j2ee.jar
User: jwalters Date: 01/07/17 19:09:33 Modified:src/lib jboss-j2ee.jar Log: Updated jboss-j2ee.jar file to Connector PFD2. Revision ChangesPath 1.5 +126 -126 jbosscx/src/lib/jboss-j2ee.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/resources/jdbc-rar/META-INF ra.xml
User: jwalters Date: 01/07/17 19:52:40 Modified:src/resources/jdbc-rar/META-INF ra.xml Log: Updated rar deployment descriptor to PFD2 transaction-support element, and jbosscx.jar to have proper error message if bad transaction-suppport element supplied by RAR developer. Revision ChangesPath 1.2 +1 -1 jbosspool/src/resources/jdbc-rar/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jbosspool/src/resources/jdbc-rar/META-INF/ra.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ra.xml2001/05/15 07:58:24 1.1 +++ ra.xml2001/07/18 02:52:40 1.2 @@ -46,7 +46,7 @@ connectionfactory-impl-classorg.jboss.pool.connector.jdbc.JDBCDataSource/connectionfactory-impl-class connection-interfacejava.sql.Connection/connection-interface connection-impl-classorg.jboss.pool.jdbc.ConnectionInPool/connection-impl-class -transaction-supportlocal_transaction/transaction-support +transaction-supportLocalTransaction/transaction-support config-property descriptionThe default user name used to create JDBC connections./description ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/lib jbosscx.jar
User: jwalters Date: 01/07/17 19:52:39 Modified:lib jbosscx.jar Log: Updated rar deployment descriptor to PFD2 transaction-support element, and jbosscx.jar to have proper error message if bad transaction-suppport element supplied by RAR developer. Revision ChangesPath 1.2 +91 -98jbosspool/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/resources/org/jboss/jms/ra/META-INF ra.xml
User: jwalters Date: 01/07/17 20:01:52 Modified:src/resources/org/jboss/jms/ra/META-INF ra.xml Log: Updated Connector related jar/rar files to pfd2 transaction-supports element in the deployment descriptor. Revision ChangesPath 1.2 +2 -2 jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ra.xml2001/04/26 21:04:06 1.1 +++ ra.xml2001/07/18 03:01:52 1.2 @@ -12,7 +12,7 @@ connectionfactory-impl-classorg.jboss.jms.ra.JmsConnectionFactoryImp/connectionfactory-impl-class connection-interfacejavax.jms.Session/connection-interface connection-impl-classorg.jboss.jms.ra.JmsSession/connection-impl-class -transaction-supportxa_transaction/transaction-support +transaction-supportXATransaction/transaction-support config-property config-property-nameJmsProviderAdapterJNDI/config-property-name config-property-typejava.lang.String/config-property-type @@ -24,4 +24,4 @@ /auth-mechanism reauthentication-supportfalse/reauthentication-support /resourceadapter -/connector \ No newline at end of file +/connector ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosscx.jar jbosspool.jar
User: jwalters Date: 01/07/17 20:01:52 Modified:src/lib jbosscx.jar jbosspool.jar Log: Updated Connector related jar/rar files to pfd2 transaction-supports element in the deployment descriptor. Revision ChangesPath 1.3 +60 -123 jboss/src/lib/jbosscx.jar Binary file 1.4 +96 -96jboss/src/lib/jbosspool.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/deploy jbosspool-jdbc.rar
User: jwalters Date: 01/07/17 20:01:52 Modified:src/etc/deploy jbosspool-jdbc.rar Log: Updated Connector related jar/rar files to pfd2 transaction-supports element in the deployment descriptor. Revision ChangesPath 1.4 +57 -59jboss/src/etc/deploy/jbosspool-jdbc.rar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/lib jboss-j2ee.jar jboss-jdbc_ext.jar
User: jwalters Date: 01/07/17 20:04:47 Modified:src/lib jboss-j2ee.jar jboss-jdbc_ext.jar Log: Updated j2ee jar files with latest connector pfd2 Revision ChangesPath 1.6 +126 -126 jbossmq/src/lib/jboss-j2ee.jar Binary file 1.4 +17 -17jbossmq/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: jboss/src/client jboss-j2ee.jar
User: jwalters Date: 01/07/17 20:10:09 Modified:src/client jboss-j2ee.jar Log: Updated jboss-j2ee.jar in the client directory as well Revision ChangesPath 1.5 +126 -126 jboss/src/client/jboss-j2ee.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/lib jboss-j2ee.jar jboss-jdbc_ext.jar
User: jwalters Date: 01/07/17 20:20:58 Modified:src/lib jboss-j2ee.jar jboss-jdbc_ext.jar Log: Updated j2ee jar files for connector pfd2 Revision ChangesPath 1.5 +126 -126 jbosstest/src/lib/jboss-j2ee.jar Binary file 1.3 +17 -17jbosstest/src/lib/jboss-jdbc_ext.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Mail Delivery Status Notification
How about whacking him on the head! By the way maybe until then we can avoid using more than 2 ! or x/X characters in the subject of any e-mails. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 3:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mail Delivery Status Notification How long before this guy gets wacked from the list? - Original Message - From: Postmaster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 12:22 PM Subject: [JBoss-dev] Mail Delivery Status Notification MAIL ESSENTIALS SENDER NOTIFICATION The following message: TO: [EMAIL PROTECTED] FROM:[EMAIL PROTECTED] DATE: Tue, 10 Jul 2001 20:15:45 +0100 Subject: Re: [JBoss-dev] IT'S ALIVE! has been quarantined by Mail Essentials for the following reason(s): Subject contains word(s)/phrase(s) '!!!' Mail essentials ___ 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: Hell---o???? RE: [JBoss-dev] cvs down this morning?
It isn't working for me either... I get an ssh error -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, July 06, 2001 11:17 AM To: [EMAIL PROTECTED] Subject: Hell---o RE: [JBoss-dev] cvs down this morning? anyone out there? I am alone on this planet...??? so I go flying a couple of hours and I come back and the planet is full of monkeys? (plug) ah come on... does the cvs work? is this really year 23999? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Friday, July 06, 2001 10:13 AM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] cvs down this morning? | | |can anyone connect to it? |I am trying to download teh new jetty for the www.jboss.org website and I |can't connect | | |:( | |marcf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED]]On Behalf Of marc ||fleury ||Sent: Friday, July 06, 2001 10:10 AM ||To: Jboss-Development@Lists. Sourceforge. Net ||Subject: [JBoss-dev] cvs down this morning? || || ||marcf || ||_ ||Marc Fleury, Ph.D ||[EMAIL PROTECTED] ||_ || || ||___ ||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-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] Where is everyone today?
The bean developer uses the home/remote interfaces, Dain is building the
plumbing that makes it transparent to the bean developer. For example if
the bean developer adds an object to a 1:n CMR under the covers the
container/persistence manager/CMP beans need to get data into the bean and
the database about that relationship. The most efficient way to do all this
is probably not with client visible features, though it isn't clear to me
that they can't be in the CMP bean implementation class as opposed to being
in interceptors and what not.
How fat is your CMP bean implementation class right now Dain? You might
want to consider putting more of this stuff in there at the remote/home
interface level as a way to build it more quickly and easier to validate
correctness. They you could always push code further into the container
later to optimize portions which don't perform.
Cheers
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 02, 2001 9:36 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Where is everyone today?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
Sundstrom
Sent: Saturday, June 30, 2001 2:48 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Where is everyone today?
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 29, 2001 3:11 PM
Subject: RE: [JBoss-dev] Where is everyone today?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Dain
Sundstrom
Sent: Friday, June 29, 2001 3:16 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] Where is everyone today?
Bill,
Thanks for the reply. I really need other people thinking about this,
because I don't understand the rest of the container.
IMHO, you shouldn't have to understand the rest of the
container. If you
use the HOME interfaces, everything will be abstracted out and
taken care
of
for you.
I agree. I can't exactly use the home interface. The home
interface doesn't
have commands such as 'set you foreign key for this relation ship
to 42.' I
No, but setRelationshipA(BeanA) could call BeanA.getPrimaryKey().
think I need to implement an interceptor to handle special messages. This
would be simmilar to how entity synchronization works. I doesn't really
matter at this point, because I have figgured out how to implement it in a
way that adding the interceptor later will be simple.
If a method call on an entity is successful, an InstanceSynchronization is
registered with the transaction. At the end of the transaction, the TM
loops through all registered synchronizations, and storeEntity is called if
isModified is true or the bean is dirty. Now, if there is no transaction,
storeEntity will be called after every entity method invocation.
Here's the deal. I delegate the actual storage of the other updated
contexts to the their respective persistence storage managers, so they
get
stored by correct data source. I also get references to the
other beans
through their container's cache.
Again, why do you talk directly with the Persistent managers? Entities
always know when they have to store themselves. You really
don't have to
worry about it.
I do, if I don't have an interceptor. Store is only called from
the entity
synchronization interceptor, and I'm currently not going through the
interceptor chain. So, someone has to call store.
Again, IMHO, you really should be going through the interceptor chain.
flameRiskI really think you have a design flaw here, if you need to access
the EntityEnterpriseContexts directly, and really should revisit why you
need to do so./flameRisk
I think the biggest problem with this implementation is that my
persistence
store is directly calling store on other persistence stores, thus
by passing
all of the code that is supposed know the right way to do this.
I just read a little about the CMR stuff in the spec. Seems
pretty nasty
to
implement and probably effects more things than just the
persistent store.
It seems that Relationships must be first class remote objects that wrap
access to their underlying entities. I'd be curious to know how you
handle
one-to-many relationships i.e.
from the spec:
public void changeTelephoneNumbers()
{
Address a = getShippingAddress();
Address b = getBillingAddress();
Collection c = b.getTelephoneNumbers();
a.setTelephoneNumbers(b.getTelephoneNumbers());
if (c.isEmpty()) { // must be true!
...
}
Wel, I don't handle 1-n relationships yet, but it is not as hard as you
think. Relationship collections are not allowed to be passed
over a remote
Sounds fishy. I need to read the spec again, but wouldn't this make
Relationship collections totally useless? Who would ever use them if you
couldn't access them through
RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
What does it do? Is it providing XA Connections for firebird? Cheers -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 11:37 AM To: [EMAIL PROTECTED] Subject: RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java Hi, My firebird resource adapter is at firebird.sourceforge.net cvs under client-java. I'm checking in my latest version which can build a rar that jboss deploys, it will create tables via jaws, but then crashes. It works ok with my test cases though! Any input on it gratefully appreciated. Thanks david jencks On 2001.06.28 13:46:27 -0400 Carlos Cardenas wrote: Thanks for your replies, I would very much like to see David's resource adapter. I personally believe that it's the way to go. I believe we can work with the firebird/postgresql ( and maybe sapdb [too bad they don't have XA supp] in the future) to get the resource adapters (jca/jdbc) working and that way simplify and make consistent jboss' code. I am sure the same approach can be taken by some other people of our community when it comes to commercial databases like oracle, informix, etc (maybe payed?). thanks and have fun, CC --- Jay Walters [EMAIL PROTECTED] wrote: My understanding of firebird is that it's a fraction of the entire interbase product missing many important features and tools. (though it has XA support?) On another note, I agree that Postgres is the only other open source database with XA support. I spent a bunch of time poking around open source databases and even my current favorite Sap DB doesn't do XA. I am pretty sure that Postgres has a JDBC 2.0 XA enabled driver, but I don't think it's stable enough to be in the standard distribution. Cheers -Original Message- From: David Jencks To: [EMAIL PROTECTED] Sent: 6/27/01 8:05 PM Subject: Re: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java Hi, Thank you for the quote. quote snipped By the way, does anyone know what is the best free database that supports XA (w/jdbc driver)? (I love postgres, but the jdbc driver doesn't have XA support (among other things), I don't even know if postgres the database has it). Is interbase (the free and gratis version) it? Interbase has supported 2pc since the 80's, in fact may have been the first db to support it (they also invented blobs, original meaning as in blob that ate cincinnatti, binary large object was a marketers invention). The semantics are a little different from what xa likes, but this can be worked around. Interclient from borland or firebird does not support xa, and suffers from ridiculous architecture. It is not worth trying to add xa to it, imho. I am working on a pure java jca/jdbc-like resource adapter for firebird dialect 3 databases that does support xa. According to my unit tests, the xa stuff works fine except for recovery ( not yet implemented) and queries seem to work fine. I'm about to see if I can package it up as a rar and use it with jboss. david jencks Hope this helps to the discussion on Isolation levels, Thanks, CC __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where is everyone today?
I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, June 29, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] Where is everyone today? Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is always on. What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need to remove the context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If this is stuff I shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 9:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation also be sure to report right here is you touch any of the information in the ctx (using setters) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Thursday, June 28, 2001 9:45 PM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation | | | | The only way I can find to get a ctx for a pk | |is from EntityInstanceInterceptor, and the only way to get to the | |EntityInstanceInterceptor is container.invoke(mi). | | no no no it's in the cache, | | container.cache.get(id) (or something like that) | | marcf | | |YES! Thanks so much. I didn't want to write the interceptor. |This is going |to be way easier. I'm going to go code now. | |-dain | |___ |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-development mailing list [EMAIL PROTECTED]
RE: [JBoss-dev] Where is everyone today?
Seems like it's always an interesting tradeoff of whether the code belongs in some runtime code (persistence manager) or in the generated code (CMP bean implementation)... I'm glad you're working on CMP 2.0, it will be good to have that implemented or JBoss. Cheers -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 3:22 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:01 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, June 29, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] Where is everyone today? Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is always on. What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need to remove the context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If this is stuff I shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 9:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation also be sure to report right here is you touch any of the information in the ctx (using setters) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf
RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
My understanding of firebird is that it's a fraction of the entire interbase product missing many important features and tools. (though it has XA support?) On another note, I agree that Postgres is the only other open source database with XA support. I spent a bunch of time poking around open source databases and even my current favorite Sap DB doesn't do XA. I am pretty sure that Postgres has a JDBC 2.0 XA enabled driver, but I don't think it's stable enough to be in the standard distribution. Cheers -Original Message- From: David Jencks To: [EMAIL PROTECTED] Sent: 6/27/01 8:05 PM Subject: Re: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java Hi, Thank you for the quote. quote snipped By the way, does anyone know what is the best free database that supports XA (w/jdbc driver)? (I love postgres, but the jdbc driver doesn't have XA support (among other things), I don't even know if postgres the database has it). Is interbase (the free and gratis version) it? Interbase has supported 2pc since the 80's, in fact may have been the first db to support it (they also invented blobs, original meaning as in blob that ate cincinnatti, binary large object was a marketers invention). The semantics are a little different from what xa likes, but this can be worked around. Interclient from borland or firebird does not support xa, and suffers from ridiculous architecture. It is not worth trying to add xa to it, imho. I am working on a pure java jca/jdbc-like resource adapter for firebird dialect 3 databases that does support xa. According to my unit tests, the xa stuff works fine except for recovery ( not yet implemented) and queries seem to work fine. I'm about to see if I can package it up as a rar and use it with jboss. david jencks Hope this helps to the discussion on Isolation levels, Thanks, CC __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss site question
In order to listen on port 80 with tomcat does one need to run Jboss as root? Does this present a security hazard - does Tomcat have any odd backdoors. Is jetty any different? Cheers Jay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss site question
Thanks Sebastien and Jim, I'm not up to date enough on Linux so I was wondering how the port forwarding was handled, I noticed there was nothing in the docs about it. I am thinking of cutting over to jboss/tomcat on my site so I can put some dynamic content up there and needed to figure this one out first. I'll RTM on ipchains... -Original Message- From: Jim Archer To: [EMAIL PROTECTED] Sent: 6/28/01 2:36 PM Subject: Re: [JBoss-dev] Jboss site question Jay, on what operating system? On Linux, running Tomcat (or any other web server) as root introduces security problems, yes. When an exploit is discovered in Tomcat, the consequences are severe if Tomcat runs as root. If it runs as a no privilidge user such as nobody (or in our case, jBoss user), the damage is quite contained (usually). This way, it can't modify itself to have new features added by hackers and it can't access critical system resources, like your password files. This has nothing to do with Tomcat. Its standard practice not to allow a server process to run as root. You can use IP chaines to let Tomcat, not running as root, to listen on port 80. Jim --On Thursday, June 28, 2001 1:36 PM -0400 Jay Walters [EMAIL PROTECTED] wrote: In order to listen on port 80 with tomcat does one need to run Jboss as root? Does this present a security hazard - does Tomcat have any odd backdoors. Is jetty any different? Cheers Jay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development I shall be telling this with a sigh Somewhere ages and ages hence: Two roads diverged in a wood, and I - I took the one less traveled by, And that has made all the difference. - Robert Frost, 1916 ___ 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 JDBCCommand.java
I think the pool hands out connections associated with a transaction, doesn't it? Unless JAWS uses a different API than everybody else does, then you can't set the isolation level in JAWS, it has to be done by the pooling software prior to assigning the connection to a transaction. If JAWS set the isolation level on a connection when it first sees it, the resource might already be in the middle of a transaction and thus cause a commit. How are people really going to use this? It seems we're a bit out of control. My experience is mostly with Oracle (this is a non-issue they'll all want read_committed since serializable is too slow), and with Informix usually want read_committed, but sometimes for speed you'll use read_uncommitted on queries. Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 1:20 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java | Sorry, I rolled back the code before you responded. If you want |me to put | it back in, I will it takes about 10 minutes. I think I made a | mistake and | made the first change to quick (it was easy) , and I think we | need to figure | out what we are doing (design before code). ok let's pause a second |Again, I'll reiterate, I strongly suggest NOT defining transaction |isolation |levels in JAWS nor at at any other level other than in the definition of a |connection pool or other data resource. You'd really have to redesign and |rewrite how JAWS interacts with data resources and frankly, I think the |abstraction that is already there provides the most flexibility(it uses |javax.sql.DataSource) in plugging in DataSources other than the stuff in |jbosspool. In fact, the EJB 2.0 spec supports some of the things |I'm trying |to say here. Isolation Levels 17.3.2 in fact I think it supports the generic pools |The following are guidelines for managing isolation levels in enterprise |beans. | |- The API for managing an isolation level is resource-manager specific. |(Therefore, the EJB architecture does not define an API for managing |isolation level.) I am glad to see that the isolation levels were removed, they are indeed JDBC specific. But JAWS is jdbc specific, jaws accesses the resource manager jdbc directly. |- If an enterprise bean uses multiple resource managers, the Bean Provider |may specify the same or different isolation level for each |resource manager. |This means, for example, that if an enterprise bean accesses multiple |resource managers in a transaction, access to each resource manager may be |associated with a different isolation level. precisely, so the isolation level is specific to a BEAN and not to a resource manager. This makes total sense, the beans know the record they are working on and what they do and can tell the driver read-only pal. In your scenario we put that knowledge at the pool level configuration and we deploy a pool PER COLLECTION OF LOCKED RECORDS we are going to access PER APPLICATION. You are saying that for each bean deployed we will create a new pool and set the isolation level on all the connections to the given isolation level. The isolation level is metadata of the pool in your case and you have a pool per different type of bean deployed. In my mind this is application/db-record metadata. |- The Bean Provider must take care when setting an isolation level. Most |resource managers require that all accesses to the resource |manager within a |transaction are done with the same isolation level. An attempt to change that is fine we don't change within the transaction. |the isolation level in the middle of a transaction may cause undesirable |behaviour, such as an implicit sync point. | |Theres more interesting stuff, but I don't feel like typing it in. | |Bill Bill are you saying.. BeanA BeanB / \ / \ PoolA PoolB PoolC PoolD --- configure here \ \ / / \ \ / / \ / \ / DB1 I am saying BeanABeanB configure here \ / PoolA | DB1 So we have one pool and you get your connection and you set the isolation level corresponding to your bean description do your work, the db knows to read that isolation level and you put the connection back when you are done and start over... btw the guys who does the work from BeanA-PoolA is jaws and he has the context on how to set the isolation levels, i.e. the metadata from the *application* since PoolA drivers support setting the isolation level outside transactions this would work. Am I correct in saying that the pool will not hand out a connection that is associated with a transaction? If so you only get connections that are clear and clean... right? I mean I don't know :) I could be wrong (really) so why the many pools ? marcf | | | |___
RE: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
And as my final 2c (at least for now) on this, I've used Allaire JRun a fair amount, they built their admin tool using JSP and running in a separate webserver (actually Oracle OAS 4.X used to do this too I think.) Anyways, they had lots of quirky little config files and the JSPs didn't really edit them right either, they'd leave bits and pieces here and there if you removed something (and yes, Oracle's web admin had the same problems). I imagine this was a quick way to get something put together though, but the tool really needs to maintain consistency. Cheers -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 10:29 AM To: [EMAIL PROTECTED] Subject: Re: The next generation GUI (was : Re: [JBoss-dev] EJX and XML) on 1-06-26 15.13, Jay Walters at [EMAIL PROTECTED] wrote: You guys wouldn't want to hear my stories... suffice it to say I agree that if you can't understand to edit the properties files by hand you probably shouldn't be editing them with a GUI... It can be a checkbox on a feature list though and sometimes that is important (even though it feels wrong!-) Yes We all probably experienced similar stories ... I do believe that one should educate to the point of understanding ... and to shield some low level stuff from people using a system ... a UI of high complexity systems need to deal with behavioural psychology and have to *?* rely on pre knowledge of its users *!* or could let users get access to the knowledge needed from the tool itself - that the UI is the facade for ... -- A modern UI need to deliver ... Education (smart doc's) Usability (efficiency) Empoverment (results) -- Lets look at the concept of EJB responsibilities that yields portability ... The Bean Provider (possible user of UI) The Container Provider (possible user of UI) The Server Provider (possible user of UI) The Application Assembler (possible user of UI) The Deployer(possible user of UI) The System Administrator(possible user of UI) -- A system that can be used will be adopted ... and a UI can help ... with Love /peter ___ 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: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
Ok, I confess, I edit it with VI. Flushed me right out of the closet... I am not a normal developer, nor having been an administrator would I like to be a normal one of those again either. -Original Message- From: Aaron Mulder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 10:35 AM To: '[EMAIL PROTECTED]' Subject: RE: The next generation GUI (was : Re: [JBoss-dev] EJX and XML) On Tue, 26 Jun 2001, Jay Walters wrote: I don't edit my xml by hand or by tool, I generate it! That's not always realistic. It works great if you're writing new code for JBoss only, but if you have a pile of existing WebLogic JARs, or you're not free to add arbitrary JavaDoc tags or whatever, a generation solution is not necessarily suitable. Aaron ___ 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] High load...
That is standard locking, you should see that everywhere unless you can set some bit to not wait for locks and just abort the statement. SQL*Plus and JDBC both look the same to the server. Of course with Oracle it won't block readers, with some other databases you will block readers in the second window as well as writers unless you are at the whatever isolation level supports dirty reads. Cheers Jay -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 12:59 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Tuesday, June 26, 2001 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, Bill: |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked operations 90% of the time. I suggested that and did take the job implementing it (though I actually did no coding yet because I have to earn some money). Marc: yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. ... WE NEED STABILITY IN FEATURES Yes, agreed. My suggestion was intended for the Rabbit Hole and originally meant to be used with commit options B/C in case there are multiple bean instances when Rabbit Hole is finished. Multiple instances would be not very usefull with pessimistic locking done on the DB, as the pessimistic behaviour (and locking waiting without a message) simply would remain viewed from the clients perspective. But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! Sorry Georg, I don't what planet I was on when I made the option A with optimistic locking comment. Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate SQL*PLUS windows. With autocommit off, it seems that if you try to update the same row in 2 different windows, one window waits until the other commits. Wonder if this will happen with JDBC as well, I'll let you knowAnybody know the behaviour on this with other DBs? Is this common locking behaviour? If so, great! All in all, I think JBOSS should delegate synching and locking to the DB wherever it can because the DB is usually more efficient at this. Also, IMHO, this is really the best way to synch multiple instances of JBoss. Regards, Bill ___ 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] finder optimization(read-ahead) phase 3
What if I've got CMP and BMP beans mixed... -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 12:17 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] finder optimization(read-ahead) phase 3 Bill Burke wrote: Can you explain this again in other words? I'm kind of confused. Are you saying you don't want to have a hashMap of preloaded data per transaction? But just one global cache? I think that is a bad idea. I'll clarify more if this is what you mean. That is what I mean (for option A only!). We can also do a look aside for option A (as you said higher up in your email) to make sure we don't read-ahead something that's already in the cache. Here goes again for my rational: In option A, we own the database, so there can be no external changes. If the data is changed by another transaction in JBoss, it will go through JAWS load code first, so the data will be taken out of the read-ahead before it is modified. Have I missed something? thanks, danch ___ 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] finder optimization(read-ahead) phase 3
Ignore me - I went onto jboss-user over the weekend and all the traffic left me a bit dizzy It is great to see so much traffic over there though. Cheers -Original Message- From: Jay Walters To: '[EMAIL PROTECTED]' Sent: 6/25/01 8:15 AM Subject: RE: [JBoss-dev] finder optimization(read-ahead) phase 3 What if I've got CMP and BMP beans mixed... -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 12:17 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] finder optimization(read-ahead) phase 3 Bill Burke wrote: Can you explain this again in other words? I'm kind of confused. Are you saying you don't want to have a hashMap of preloaded data per transaction? But just one global cache? I think that is a bad idea. I'll clarify more if this is what you mean. That is what I mean (for option A only!). We can also do a look aside for option A (as you said higher up in your email) to make sure we don't read-ahead something that's already in the cache. Here goes again for my rational: In option A, we own the database, so there can be no external changes. If the data is changed by another transaction in JBoss, it will go through JAWS load code first, so the data will be taken out of the read-ahead before it is modified. Have I missed something? thanks, danch ___ 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-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
netbeans is another possibility... -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 3:36 PM To: [EMAIL PROTECTED] Subject: The next generation GUI (was : Re: [JBoss-dev] EJX and XML) on 1-06-25 19.30, marc fleury at [EMAIL PROTECTED] wrote: The next generation GUI Could be built using a set of extension to a freeware shell like the Together Community Edition 5.0 http://www.togethercommunity.com/community-edition.shtml or some other free tool with easy yet powerfull plugin capability ... couse it gives direct down and into the func of the tool ... So : What is the spec for the tool ? ... What is the wishlist for the tool ? ... I am not commiting here just curious to understand what it absolutely has to do -- also what it could be made up in dreams to do ... ex. rollover logs - collect statistics - fail/load notifications etc. ? ... besides conf ! ? ... skin'able ? ... ;-) /peter ___ 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
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] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption
When using BMP I can put SQL anywhere, so I can modify my setAddress() method to execute the SQL to update the persistent store directly, no muss, no fuss. Note that this method updates the state of the object in memory and in the database, so it can work with isModified() to avoid the execution of ejbStore() at commit time if nothing else changed. In fact I'd probably include the call to remove the old address there as well if that makes sense. Cheers Jay -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Monday, June 18, 2001 9:50 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption Hi Gentlemen, Jay Walters wrote: Seems like an application requiring a CMP Persistence Manager and EJB container to execute SQL in a specific order might be asking a bit much to me... and Bill Burke replied: You'd have the same type of problems with BMP, wouldn't you? Sorry G's, I still can't see the point here. With BMP simply ejbCreate/Store/Remove is called at the appropriate places, especially ejbStore is called after every business method, isn't it? If not, would someone PLEASE point me to the code that does actually deferring the SQL, I just again spent 2 hours in org.jboss.ejb.** hunting for it. I'm pretty sure you're wrong here. BMP in jboss does NOT guarantee SQL ordering. BMP uses the same interceptors as CMP(look in standardjboss.xml) and there is no code in these Entity interceptors that differentiate between BMP and CMP. Somebody please correct me if I'm wrong because I'd really like to nail this down. If I'm right, the BMP guy has all control over execution of SQL by simply doing the OO operations in some order (having referential integrity in the back of his head). Besides, is such a thing as RI useless/hindering in the OO world? I don't think so, even the pure OO guru respects integrity by i.e. not changing essential things before he knows for sure, that relatet changes can be done. (Else he would be no guru and should learn a session from the relational boys). Not true, see above. And, last but not least, in the EJB context, heavily tied to relational store tier (by practical implementations and at least 'between the lines' of the EJB specs), it would be a shame to leave people without referential integrity, by not allowing them to have it on the store (Database) and not providing it in the next higher level by declaration (the entiy bean level). Again, when the BMP guys have full control, why should EJB Server/ Container developers want to leave the CMP guys in the wet? Note, that I'm not against the push() thing just published on top the EJB 2 requirement to 'store before find', but I consider it 'Janus' headed: one side parfumed like a feature, the other one stinking like a workaround. I disagree this is klugy. I think the spec is trying to help with referential integrity while still giving the Container some room to optimize DB access. Back to my past suggestion of respecting the ORDER of OO calls: A simple, but imperformant, solution would be to execute storeEntity() after each business method and in create/remove. I believe now, that the real flaw is caused by the fact, that the EJB specs consider every field/attribute of a bean to be equal in semantics to each other, with the exception of the Primary Key field(s). But they didn't learn their lession really from the relational poor mens! They COMPLETELY ignore the very different semantics of FOREIGN KEYS (place holders for Associations of all sorts). This discussion threads problem never comes up, when changing simple attributes/fiels, that ain't related to anything, but the primary key of the bean instance (1:1, normally). But it shows up, when attributes, that represent associations, are modified. JAWS/JBoss needs to know about the SEMANTICS of fields/columns and then can come up with performant/'intelligent' handling: If deferral to commit time is suggested, then QUEUING up all store requests related to one TX (including create(), remove() and store() and possibly find() for DIFFERENT instances/beans) will help: if ANY store request affects data with FOREIGN KEY / Association semantics, the queue must be processed physically to the underlying store, until empty, before executing the call with association semantics (only as a first attempt, we will be better in a few days!). Thus several changes to simple attributes of the same bean instance intermixed with creation/removal of other bean instances would nicely be accumulated to only one store() operation (and several unrelated create/delete_stores
RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption
I haven't used CMP so I'm not sure what issues there might be making them play together. With BMP nothing funky happens under the covers. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 10:18 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption Duh!Soyy You could probably do the same with CMP/JAWS, correct? bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters Sent: Tuesday, June 19, 2001 9:55 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption When using BMP I can put SQL anywhere, so I can modify my setAddress() method to execute the SQL to update the persistent store directly, no muss, no fuss. Note that this method updates the state of the object in memory and in the database, so it can work with isModified() to avoid the execution of ejbStore() at commit time if nothing else changed. In fact I'd probably include the call to remove the old address there as well if that makes sense. Cheers Jay -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Monday, June 18, 2001 9:50 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption Hi Gentlemen, Jay Walters wrote: Seems like an application requiring a CMP Persistence Manager and EJB container to execute SQL in a specific order might be asking a bit much to me... and Bill Burke replied: You'd have the same type of problems with BMP, wouldn't you? Sorry G's, I still can't see the point here. With BMP simply ejbCreate/Store/Remove is called at the appropriate places, especially ejbStore is called after every business method, isn't it? If not, would someone PLEASE point me to the code that does actually deferring the SQL, I just again spent 2 hours in org.jboss.ejb.** hunting for it. I'm pretty sure you're wrong here. BMP in jboss does NOT guarantee SQL ordering. BMP uses the same interceptors as CMP(look in standardjboss.xml) and there is no code in these Entity interceptors that differentiate between BMP and CMP. Somebody please correct me if I'm wrong because I'd really like to nail this down. If I'm right, the BMP guy has all control over execution of SQL by simply doing the OO operations in some order (having referential integrity in the back of his head). Besides, is such a thing as RI useless/hindering in the OO world? I don't think so, even the pure OO guru respects integrity by i.e. not changing essential things before he knows for sure, that relatet changes can be done. (Else he would be no guru and should learn a session from the relational boys). Not true, see above. And, last but not least, in the EJB context, heavily tied to relational store tier (by practical implementations and at least 'between the lines' of the EJB specs), it would be a shame to leave people without referential integrity, by not allowing them to have it on the store (Database) and not providing it in the next higher level by declaration (the entiy bean level). Again, when the BMP guys have full control, why should EJB Server/ Container developers want to leave the CMP guys in the wet? Note, that I'm not against the push() thing just published on top the EJB 2 requirement to 'store before find', but I consider it 'Janus' headed: one side parfumed like a feature, the other one stinking like a workaround. I disagree this is klugy. I think the spec is trying to help with referential integrity while still giving the Container some room to optimize DB access. Back to my past suggestion of respecting the ORDER of OO calls: A simple, but imperformant, solution would be to execute storeEntity() after each business method and in create/remove. I believe now, that the real flaw is caused by the fact, that the EJB specs consider every field/attribute of a bean to be equal in semantics to each other, with the exception of the Primary Key field(s). But they didn't learn their lession really from the relational poor mens! They COMPLETELY ignore the very different semantics of FOREIGN KEYS (place holders for Associations of all sorts). This discussion threads problem never comes up, when changing simple attributes/fiels, that ain't related to anything, but the primary key of the bean instance (1:1, normally). But it shows up, when attributes, that represent associations, are modified. JAWS/JBoss needs to know about
RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption
Seems like an application requiring a CMP Persistence Manager and EJB container to execute SQL in a specific order might be asking a bit much to me... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 18, 2001 12:39 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption Bugs item #434227, was updated on 2001-06-18 09:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=434227group_id= 22866 Category: JBossCMP Group: v2.2 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ejbStore delay can lead to DB corruption Initial Comment: The caching of database updates until the end of a transaction can lead to data corruption if RI constraints are in place. Example: CreditCard cc = cch.findByPrimaryKey(creditCardID); CreditCardRecord ccr = cc.getRecord(); //Get the address that this credit card is currently pointing to MemberCompanyAddress mca = mcah.findByPrimaryKey(new MemberCompanyAddressPK(ccr.billing_address_id)); //Change the address to a different one ccr.billing_address_id = newBillingAddressID.intValue (); //Write the changes to the bean object cc.setRecord(ccr); //Remove the old address mca.remove(); Because the UPDATE that the setRecord() call is delayed until the end of the TX, the call to remove() is operating on the old snapshot of the database, not the post-UPDATE state that the developer expects. Corruption can result if a ON DELETE CASCADE RI constraint is on the Address table. (As this will remove the underlying CreditCard record) Two possible solutions: Allow a developer to force a flush of the transaction cache to the DB Automatically flush bean object setXXX() operations to the DB based on the state of a flag in the deployment descriptor. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=434227group_id= 22866 ___ 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] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption
With BMP I would implement a more complex method (or methods across the beans) which handle all the stuff in one shot and in the right order. I would just put the needed SQL right into the business methods. The issue here is that he's trying to compose a single larger operation from 3 small operations that are order dependent, but CMP EJB doesn't provide any guarantee on the order of execution. It says things like the container can sync state when it wants, or the container can defer the execution of remove from persistent store until the end of transaction. It doesn't say that it's supposed to support declarative RI constraints in the persistent store. Don't get me wrong, I'm not saying EJB should blow off RI, just that the current specs seem to reserve RI for the container and don't really do anything to support it in the database. There is no reason that JAWS can't be smart enough to allow the database to do the RI thing, it'd just be a bunch of work (which I'm not volunteering to do!) Some database products (Oracle) allow you to defer RI checking until commit time which allows you to avoid this type of problem. Cheers -Original Message- From: Bill Burke To: [EMAIL PROTECTED] Sent: 6/18/01 4:34 PM Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption You'd have the same type of problems with BMP, wouldn't you? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters Sent: Monday, June 18, 2001 3:35 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption Seems like an application requiring a CMP Persistence Manager and EJB container to execute SQL in a specific order might be asking a bit much to me... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 18, 2001 12:39 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption Bugs item #434227, was updated on 2001-06-18 09:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=434227 group_id= 22866 Category: JBossCMP Group: v2.2 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ejbStore delay can lead to DB corruption Initial Comment: The caching of database updates until the end of a transaction can lead to data corruption if RI constraints are in place. Example: CreditCard cc = cch.findByPrimaryKey(creditCardID); CreditCardRecord ccr = cc.getRecord(); //Get the address that this credit card is currently pointing to MemberCompanyAddress mca = mcah.findByPrimaryKey(new MemberCompanyAddressPK(ccr.billing_address_id)); //Change the address to a different one ccr.billing_address_id = newBillingAddressID.intValue (); //Write the changes to the bean object cc.setRecord(ccr); //Remove the old address mca.remove(); Because the UPDATE that the setRecord() call is delayed until the end of the TX, the call to remove() is operating on the old snapshot of the database, not the post-UPDATE state that the developer expects. Corruption can result if a ON DELETE CASCADE RI constraint is on the Address table. (As this will remove the underlying CreditCard record) Two possible solutions: Allow a developer to force a flush of the transaction cache to the DB Automatically flush bean object setXXX() operations to the DB based on the state of a flag in the deployment descriptor. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=434227 group_id= 22866 ___ 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-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] JBoss on JBoss
Really, I was just asking the question. You're doing it differently than I would and I want to understand why. Sounds like two things (1) Hey why use apache is tomcat can serve static content. Plus seems like you made a bunch of stuff into jsps. (2) Pure java and some other 4th gen (JBoss 3.0) philosophical stuff. Thanks for telling us why. Don't worry about Tomcat, we can always go with Jetty! Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 9:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss on JBoss and you gonna run it for me? unless you put your work on the line, don't put your mouth and opinions in front I just realized I updated the cvs and the procedures wiped out the current cvs so we REALLY have to make the switch now... prematurely but so it goes... that is when I close my eyes and take a leap of faith. Tomcat better not let me down... you guys better help if Tomcat does go down... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V. |Vinay Menon |Sent: Friday, June 15, 2001 4:12 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] JBoss on JBoss | | |I seem to agree with Jay. The web server in Tomcat sucks. It is very slow! | |Vinay |- Original Message - |From: Jay Walters [EMAIL PROTECTED] |To: 'Schaefer, Andreas ' [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Sent: Friday, June 15, 2001 1:34 AM |Subject: RE: [JBoss-dev] JBoss on JBoss | | | I fail to see how serving .gif files from tomcat shows off |jboss. i am all | for using jboss to handle dynamic content on the site, just trying to |figure | out why every hit has to go there. Is that how you expect people to use |it | | Cheers | | -Original Message- | From: Schaefer, Andreas | To: '[EMAIL PROTECTED]' | Sent: 6/14/01 1:34 PM | Subject: RE: [JBoss-dev] JBoss on JBoss | | What a question ! | | How do you want to convince other people to use JBoss when | you aren't going to use your own tool. Either JBoss is | ready to be used in production and then we should use it. | | BTW We are going to create an interactive Survey which | must store the info in a DB. | | Mad Andy | | -Original Message- | From: Jay Walters [mailto:[EMAIL PROTECTED]] | Sent: Thursday, June 14, 2001 9:05 AM | To: '[EMAIL PROTECTED]' | Subject: RE: [JBoss-dev] JBoss on JBoss | | | Why the decision to remove apache and serve everything from tomcat? | | Cheers | | -Original Message- | From: marc fleury [mailto:[EMAIL PROTECTED]] | Sent: Thursday, June 14, 2001 11:50 AM | To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. | Sourceforge. Net | Subject: [JBoss-dev] JBoss on JBoss | | | since I am done porting the website and adding a few things, | it will run on | JBoss/Tomcat now. | | However not all is ported yet, most notably petstore is | finicky and the | order in which we deploy the ears is important (go figure). | | So bear with us and the website as we move all this online. | Also JIVE will | be installed and jboss-user going online soon. Time to taste our own | medicine. If we are going to evangelize on our technology we | better have | the track record *at home* to support it. | | Again for the next few days the website will be a little | messy and under | construction, thanks for your understanding, | | regards | | marcf | | _ | Marc Fleury, Ph.D | [EMAIL PROTECTED] | _ | | | | ___ | 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-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-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-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss on JBoss
I have no basis to make any comment, I've never even tried to start Jetty. Just suggesting we have two bundles for download, if the Tomcat one is not suitable for some reason, I would try Jetty next. Tomcat is in general a slow servlet engine, but my experience was comparing it with COTS servlet engines not other open source ones, and that is somewhat dated by now. I do not know how much improvement they have made in the 3.2 releases, though people seem to think there is a good amount. One issue with Apache/Tomcat and the connector in the middle is that you've got another network hop in the middle of processing servlet requests. I am not sure how much that slows it down vs any speedup of static content serving. My previous employer, an internet startup, used Java webserver for a long time, before moving to Apache/Resin. We didn't have tons of traffic ~200K page views/day over 2-3 PIII 450 boxes but they were never too busy, so I am sure a pure Java solution will work. Of course how do you do CGI or PHP using Tomcat? (he he) Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 10:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss on JBoss Off Topic, Is Jetty better? We're using Jetty and were considering moving to Tomcat because it seemed the user base was higher. Let me know, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters Sent: Friday, June 15, 2001 9:45 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] JBoss on JBoss Really, I was just asking the question. You're doing it differently than I would and I want to understand why. Sounds like two things (1) Hey why use apache is tomcat can serve static content. Plus seems like you made a bunch of stuff into jsps. (2) Pure java and some other 4th gen (JBoss 3.0) philosophical stuff. Thanks for telling us why. Don't worry about Tomcat, we can always go with Jetty! Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 9:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss on JBoss and you gonna run it for me? unless you put your work on the line, don't put your mouth and opinions in front I just realized I updated the cvs and the procedures wiped out the current cvs so we REALLY have to make the switch now... prematurely but so it goes... that is when I close my eyes and take a leap of faith. Tomcat better not let me down... you guys better help if Tomcat does go down... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V. |Vinay Menon |Sent: Friday, June 15, 2001 4:12 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] JBoss on JBoss | | |I seem to agree with Jay. The web server in Tomcat sucks. It is very slow! | |Vinay |- Original Message - |From: Jay Walters [EMAIL PROTECTED] |To: 'Schaefer, Andreas ' [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Sent: Friday, June 15, 2001 1:34 AM |Subject: RE: [JBoss-dev] JBoss on JBoss | | | I fail to see how serving .gif files from tomcat shows off |jboss. i am all | for using jboss to handle dynamic content on the site, just trying to |figure | out why every hit has to go there. Is that how you expect people to use |it | | Cheers | | -Original Message- | From: Schaefer, Andreas | To: '[EMAIL PROTECTED]' | Sent: 6/14/01 1:34 PM | Subject: RE: [JBoss-dev] JBoss on JBoss | | What a question ! | | How do you want to convince other people to use JBoss when | you aren't going to use your own tool. Either JBoss is | ready to be used in production and then we should use it. | | BTW We are going to create an interactive Survey which | must store the info in a DB. | | Mad Andy | | -Original Message- | From: Jay Walters [mailto:[EMAIL PROTECTED]] | Sent: Thursday, June 14, 2001 9:05 AM | To: '[EMAIL PROTECTED]' | Subject: RE: [JBoss-dev] JBoss on JBoss | | | Why the decision to remove apache and serve everything from tomcat? | | Cheers | | -Original Message- | From: marc fleury [mailto:[EMAIL PROTECTED]] | Sent: Thursday, June 14, 2001 11:50 AM | To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. | Sourceforge. Net | Subject: [JBoss-dev] JBoss on JBoss | | | since I am done porting the website and adding a few things, | it will run on | JBoss/Tomcat now. | | However not all is ported yet, most notably petstore is | finicky and the | order in which we deploy the ears is important (go figure). | | So bear with us and the website as we move all this online. | Also JIVE will | be installed and jboss-user going online soon. Time to taste our own | medicine. If we are going to evangelize on our technology we | better have | the track record *at home* to support it. | | Again
RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
Hey, looks good and runs good. One sore spot, tried the search documentation feature looking for db2 and oracle and got a 404 error back both times. Great work Marc. Now we can eat our down dogfood... Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 11:10 AM To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT A big, sloppy, thank you thank you thank you to the French Brigade at Telecom Paris for being alert and helping out in firefighter mode. Sebastien fixed it.. Sebastien you the man, discreet as ever, but there when it really really counts... thanks man... so anyway... jboss.org is back online and it is all running on JBoss/Tomcat. Pure JSP etc etc... thanks to those who helped out and regards marcf PS: come on come on go try it out already ! _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ 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] ejbStore() delay seems to be a serious problem
Sorry. Ok so I'll read a little slower next time. Now that you've explained it, how would it work to use database RI underneath an EJB application. If the bean is in memory but disappears from the database that isn't all that good. If he's using commit option C, then next client to reference the bean will get what? Object does not exist when they try to execute a method on the bean? Cheers -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 1:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
I am wondering how many people are using declarative RI and entity beans? I am sure the DBAs like the RI stuff in the database, but EJB seems to like to be the only game in town - for example leaving it up to the container to issue the SQL in whatever order it wants. Cheers -Original Message- From: David Esposito [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 1:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem That's what I want ... I don't want the data to be committed, I just need it to be visible by other operations that occur under the same transaction context. In my example in my email, I neglected to mention what actually happens when you execute my block of code: The database throws a hemorrhage because there is a non-cascading delete RI constraint between the member_company_address table and the credit_card table. The situation would be even more serious if the constraint WERE cascading (ON DELETE CASCADE) ... In that case, the remove() method on my address object would actually remove the credit_card record in the DB that JBOSS had its hands on. ... Both of which would be avoided if the UPDATE to the credit_card record had happened immediately when i issued my setXXX() method on the remote object .. I am surprised that I am the only one that has raised this particular example. It seems like it's something that people would do every day. I could come up with several other illustrative examples of where this is a problem ... but I think this one is the simplest to understand ... -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Friday, June 15, 2001 12:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem Why is this a serious problem? The weblogic docs for the flag you mention indicate the commit is still not done until the end of the transaction and that you would only notice this if your db allows for uncommitted reads. From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164 Using delay-updates-until-end-of-tx to Change ejbStore() Behavior By default, WebLogic Server updates the persistent store of all beans in a transaction only at the completion (commit) of the transaction. This generally improves performance by avoiding unnecessary updates and repeated calls to ejbStore(). If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow other database users to view the intermediate results of in-progress transactions. In this case, the default WebLogic Server behavior of updating the datastore only at transaction completion may be unacceptable. You can disable the default behavior by using the delay-updates-until-end-of-tx deployment element. When you set this element to false, WebLogic Server calls ejbStore() after each method call, rather than at the conclusion of the transaction. Note: Setting delay-updates-until-end-of-tx to false does not cause database updates to be committed to the database after each method invoke; they are only sent to the database. Updates are committed or rolled back in the database only at the conclusion of the transaction. - Original Message - From: David Esposito [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 9:01 AM Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem Hello all, I have spent the past few hours reading up on other people with similar problems to mine. So I am familiar with what the EJB spec says (somewhat related to the diamond scenario (11.7.1 of the EJB Spec)) with respect to when a Bean is required to write its data out to persistent storage. However, this seems to be counterintuitive and is a serious problem for operations that manipulate multiple data sources. ___ 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-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] No storeEntity before ejbFindMETHOD
Well I am hoping I am just confused and have misunderstood you.
It appeared that you said JDBC connections and Sql*plus ones were different,
and that a if I perform an insert inside a transaction using JDBC that
within the same transaction I would not be able to read the row inserted.
If in fact you did say that there are two things which are significant.
First, the server does not distinguish by client type and both SQL*Plus and
JDBC drivers look essentially the same to it. They both use the same wire
protocol to speak with the server.
On the second issue, read committed has to do with other transactions. Run
the embedded JDBC program... you might need to fix up the connection URL.
import java.sql.*; // JDBC classes
public class Foo {
public static void main( String[] args ) throws SQLException {
// Get connection to the database
DriverManager.registerDriver( new oracle.jdbc.driver.OracleDriver()
);
Connection con = DriverManager.getConnection(
jdbc:oracle:thin:@localhost:1521:ORCL, scott, tiger );
/* Create the table */
Statement stmt = con.createStatement();
stmt.execute( CREATE TABLE FOO ( X VARCHAR2(32)) );
con.setAutoCommit( false );
stmt.executeUpdate( INSERT INTO FOO VALUES ('Gina') );
/* Won't see Gina here! */
ResultSet rs = stmt.executeQuery( SELECT X FROM FOO );
System.out.println( Gina says see nothing );
while( rs.next() ) {
System.out.println( Oh oh, Found + rs.getString( 1 ));
}
rs.close();
con.rollback();
/* Won't see Gina here for sure! */
rs = stmt.executeQuery( SELECT X FROM FOO );
System.out.println( Won't find anything here! );
while( rs.next() ) {
System.out.println( Found + rs.getString( 1 ));
}
/* All done, drop the table */
stmt.execute( DROP TABLE FOO );
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Actually Oracle will do this, are you using Oracle? You can change the
constraint checking to be deferred until commit.
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 3:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
Hi,
Well, another possibility would be ketting your db vendor to check fk
constraints only on transaction boundaries, which would imho make the most
sense, however in the real world, Bill Burke just added (to cvs/2.3-2.4 I
think) some code that forces the container to store all modifications
before executing any finder methods. You could in your example leverage
this feature by:
get ccr.
remember address id
change address id
find old address from remembered address id (forces write of the change you
just made)
remove old address.
I don't know if you can always rearrange your operations to avoid extra
finder calls, but presumably you can always make an extra one to force
writes.
It is possible that I have misinterpreted his code and you have to find an
entity bean of the same class as the one you changed, but I don't think
this is the case.
david jencks
On 2001.06.15 12:01:09 -0400 David Esposito wrote:
Hello all,
I have spent the past few hours reading up on other people with similar
problems to mine. So I am familiar with what the EJB spec says (somewhat
related to the diamond scenario (11.7.1 of the EJB Spec)) with respect
to
when a Bean is required to write its data out to persistent storage.
However, this seems to be counterintuitive and is a serious problem for
operations that manipulate multiple data sources.
The flaw is that the Container writes changes out to persistent storage
immediately for remove() (ejbRemove()) and create() (ejbCreate())
operations, however, it doesn't write changes out for other Bean business
methods until the commit() section of the transaction.
Take the following method from my Stateless SessionBean (transaction set
to
Required for the SSB and for the two CMP beans that it is manipulating)
public Integer runTest(Integer creditCardID, Integer newBillingAddressID)
throws EJBException
{
CreditCardHome cch =
(CreditCardHome)TradeIMEJBTools.getHome(blah/CreditCardHome,CreditCardHome
.class);
MemberCompanyAddressHome mcah =
(MemberCompanyAddressHome)TradeIMEJBTools.getHome(blah/MemberCompanyAddress
Home,MemberCompanyAddressHome.class);
try
{
CreditCard cc = cch.findByPrimaryKey(creditCardID);
CreditCardRecord ccr = cc.getRecord();
//Get the address that this credit card is currently pointing to
MemberCompanyAddress mca = mcah.findByPrimaryKey(new
MemberCompanyAddressPK(ccr.billing_address_id));
//Change the address to a different one
ccr.billing_address_id = newBillingAddressID.intValue();
//Write the changes to the bean object
cc.setRecord(ccr);
//Remove the old address
mca.remove();
return null;
}
catch(Exception e)
{
System.out.println(Error creating record! + e);
throw new EJBException(Failure creating records!);
}
}
Here's what the average guy would think that this does to the DB:
BEGIN;
SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}
oldBillingAddressID = {previousQuery}.billing_address_id
UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}
DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}
COMMIT;
But in fact, the order of operations are as follows:
BEGIN;
SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}
oldBillingAddressID = {previousQuery}.billing_address_id
DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}
UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}
COMMIT;
This is a serious problem ... Weblogic has implemented a
delay-updates-until-end-of-tx parameter to add to the deployment
descriptor to allow a developer to override this behavior... Is there any
chance that the same can be done to JBOSS? Borland App Server supposedly
has
something similar ... If not, does anyone have any way to work around
this
problem without writing my own BMP beans and calling ejbStore() manually
after each business method to the bean? Ideally, it would be nice to also
have a parameter to add to the deployment descriptor to force an
ejbLoad()
before each business method ... I understand all of the performance
implications of doing such things, this is why it seems like it needs to
be
part of each beans deployment descriptor rather than a global setting for
all entity beans.
I looked at the Interceptor classes in the org.jboss.ejb.plugins
directory
and feel that it is beyond my capability to actually
RE: [JBoss-dev] JBoss on JBoss
Why the decision to remove apache and serve everything from tomcat? Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 11:50 AM To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-dev] JBoss on JBoss since I am done porting the website and adding a few things, it will run on JBoss/Tomcat now. However not all is ported yet, most notably petstore is finicky and the order in which we deploy the ears is important (go figure). So bear with us and the website as we move all this online. Also JIVE will be installed and jboss-user going online soon. Time to taste our own medicine. If we are going to evangelize on our technology we better have the track record *at home* to support it. Again for the next few days the website will be a little messy and under construction, thanks for your understanding, regards marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ 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] JBoss on JBoss
I fail to see how serving .gif files from tomcat shows off jboss. i am all for using jboss to handle dynamic content on the site, just trying to figure out why every hit has to go there. Is that how you expect people to use it Cheers -Original Message- From: Schaefer, Andreas To: '[EMAIL PROTECTED]' Sent: 6/14/01 1:34 PM Subject: RE: [JBoss-dev] JBoss on JBoss What a question ! How do you want to convince other people to use JBoss when you aren't going to use your own tool. Either JBoss is ready to be used in production and then we should use it. BTW We are going to create an interactive Survey which must store the info in a DB. Mad Andy -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 9:05 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] JBoss on JBoss Why the decision to remove apache and serve everything from tomcat? Cheers -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 11:50 AM To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-dev] JBoss on JBoss since I am done porting the website and adding a few things, it will run on JBoss/Tomcat now. However not all is ported yet, most notably petstore is finicky and the order in which we deploy the ears is important (go figure). So bear with us and the website as we move all this online. Also JIVE will be installed and jboss-user going online soon. Time to taste our own medicine. If we are going to evangelize on our technology we better have the track record *at home* to support it. Again for the next few days the website will be a little messy and under construction, thanks for your understanding, regards marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ 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-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] First small patch for jboss-j2ee
Applied to the mainline jboss-j2ee module ... Cheers Jay -Original Message- From: Jesper Pedersen To: [EMAIL PROTECTED] Sent: 6/12/01 6:49 AM Subject: [JBoss-dev] First small patch for jboss-j2ee Mhmm I'm resending this just in case ... --- Hi. Here is my first small patch for jboss-j2ee. It removes the abstract keyword from the interfaces in javax.ejb and javax.ejb.spi. It also updates the documentation. Note: There was an error in javax.ejb.MessageDrivenBean; the two method throws EJBException instead of RemoteException. Someone with write-access: please review the patch and commit. I'll start to work my way through the other packages in the module. Kind Regards, Jesper -- Jesper Pedersen, M.Sc. C.S.E Open Source Solution Manager Sun Certified Java 2 Developer IT+ A/S Phone: +45 86 78 21 00 Brendstrupgaardsvej 7 Fax: +45 86 78 21 02 DK-8200 Aarhus N Direct:+45 87 40 08 49 Denmark Email: [EMAIL PROTECTED] ejb.patch.gz ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS of confusion
What is the current state of things with regards to branch vs main for 2.3/4 vs rabbit hole? Seems like some emails I just saw said we'll branch 2.3/4 and the mainline will be rabbit hole? (That way makes better sense than branching new development I think.) Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Reason for abstract methods in jboss-j2ee
Not from the point of view of how things work. Interfaces are always abstract. I am pretty sure that is the way sun declares them which is why we did them that way first time. Javadoc certainly won't hurt. By he way Marc F, Jesper did the first pass of EJB 2.0 support for the jboss-j2ee project so he's been contributing... Cheers -Original Message- From: Jesper Pedersen To: [EMAIL PROTECTED] Sent: 6/11/01 2:39 AM Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee Hi. Is there a reason for declaring the interface methods in jboss-j2ee for abstract ? If not I'll clean it up and add JavaDoc ;) Cheers, Jesper -- Jesper Pedersen, M.Sc. C.S.E Open Source Solution Manager Sun Certified Java 2 Developer IT+ A/S Phone: +45 86 78 21 00 Brendstrupgårdsvej 7 Fax: +45 86 78 21 02 8200 Århus N Direct:+45 87 40 08 49 Denmark Email: [EMAIL PROTECTED] ___ 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] Reason for abstract methods in jboss-j2ee
You're right. I can't find the javadoc on my machine that had the abstract methods in interfaces, but the only files I actually did myself were the Connector API ones and I don't seem to have that Javadoc right now. Maybe it was in the O'Reilly book appendix? I remember thinking it was odd when I saw it. It's not important. As I said in my previous email the abstract keyword on an interface method clearly will have no impact, so feel free to change it. As for the javadoc, we had a pretty fair amount on the initial checkin, but I wouldn't be surprised if we missed some, or if some is missing on the latest 2.0 bits so again feel free to add. Cheers -Original Message- From: Jesper Pedersen [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 7:07 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee You can say that methods in an interface are abstract, since the interface doesn't contain an implementation. But I see no reason for declaring them abstract, since the abstract keyword only has meaning when used in a class definition. Sun doesn't declare methods in the interfaces abstract -- check the Javadoc generated from EJB 2.0 PFD2 compared to jboss-j2ee. I think we -- and I would be willing to do that -- should clean the interfaces such that they don't use the abstract keyword. And a bit more Javadoc wouldn't hurt ;) Cheers, Jesper On Monday 11 June 2001 12:22, you wrote: Not from the point of view of how things work. Interfaces are always abstract. I am pretty sure that is the way sun declares them which is why we did them that way first time. Javadoc certainly won't hurt. By he way Marc F, Jesper did the first pass of EJB 2.0 support for the jboss-j2ee project so he's been contributing... Cheers -Original Message- From: Jesper Pedersen To: [EMAIL PROTECTED] Sent: 6/11/01 2:39 AM Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee Hi. Is there a reason for declaring the interface methods in jboss-j2ee for abstract ? If not I'll clean it up and add JavaDoc ;) Cheers, Jesper ___ 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] Fast Updates Based on Row ID
Why do you think the rowid won't be immediately available? -Original Message- From: K.V. Vinay Menon To: [EMAIL PROTECTED] Sent: 6/9/01 11:47 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Georg, Dan Alright. First of all do we really want to modify the insert sql to return the oracle rowid and hence end up putting oracle specific code. Believe the only issue we have is that given the fact that updates will be based on the row id and immediately after inserts the rowid would still be null we might end up with a few problems. Now, that is where I think we need to make the documentation work. If a person wishes to use rowid based updates etc then it must be clearly stated that the create method be defined in a container transaction that has value 'RequiresNew'. That way, the insert would be committed immediately and even if the person did an update after the insert it would basically have the rowid value updated. I am just trying to avoid putting in code that is specific to any dbms - just require that a dbms provide stable rowids. Do you see a problem with this? My views. Your thoughts? Vinay - Original Message - From: Georg Rehfeld [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 09, 2001 5:40 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Hi Dan and Vinay, The reason I was suggesting an oracle specific option name was because I really think that we need to use the Oracle specific syntax to return the rowid value on inserts. Oops, I forgot about that. But Vinay is right, a stable ROWID might be present in several other databases already or in future. The 'insert ... select into' syntax today seems to be Oracle 8 specific (remember, Oracle 7 does not have it), but could make it into some standard? At least one and the other are not too closely related, this syntax especially can get back whatever you want from the just inserted row, not only the ROWID, but even some sequence value, some expression list to be more general. And other DB's having a stable ROWID ain't lost, as Vinay's code now falls back to the PK when a ROWID value isn't available. So I suggest 'stable-rowid-column' (including good docs) and a new tag 'insert-select-list' specifying a comma separated list of expressions to select from the inserted row and an appropriate number of placeholders for the result after a semicolon. (Or better, feel free to define the syntax, you got the idea). bye, my very best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ 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-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
I suppose it would get us out of the problem of being certified as J2EE compliant as well... -Original Message- From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! snip/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Fast Updates Based on Row ID
Use insert ... returning rowid into ? -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 12:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Hi, I may be wrong about oracle rowid changing on row update, it's been a couple of years. However interbase/firebird dbkey definitely does change on update, and I think someone mentioned the sql server analogue does too. In this situation, it seems to me that commit option A cannot be used, since to get a valid rowid, you have to read the db within the same transaction you are updating in. Also, even in Oracle, how can this be used with a newly inserted bean? create --inserts row in db later in same transaction, change values on this bean, the generated save has no rowid unless you fetched it in perhaps ejbpostcreate??? If you can fix this one, perhaps it can also be used to fetch values supplied by triggers on insert, such as sequence/generators used for abstract id. Am I wrong here? Could you explain in detail how this will work? Thanks david jencks On 2001.06.06 10:50:53 -0400 K.V. Vinay Menon wrote: The ROW ID bit does not touch ANY other portion in the JBoss source except for a) Generating SQLs b) Setting parameters. Options A,B and C should work as usual, correct me if I am wrong. As for option D, I am suprised that it has become part of our 'standard' commit options. I wrote some code and never had a chance to commit it and unless someone else has commited stuff for option D let me know and I'll have to commit the code! Vinay - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 2:40 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Hi, This looks very interesting. I'm kind of too lazy to read your code to find out the answer for myself... My impression is that Oracle ROWID and similar facilities such as Interbase/firebird dbkey are stable only within a transaction, and in fact expected to change with any update. Could you please explain how your new feature guarantees updating the correct row with commit options A, B, C, and D? Thanks david jencks On 2001.06.06 08:56:02 -0400 K.V. Vinay Menon wrote: Hi Marc, When you were here in London we'd discussed adding functionality to use things like ROWID for fast updates and deletes [as opposed to using primary keys]. I have been able to implement this by 1. Adding a field in jaws.xml called rowid-column name. This is ROWID for Oracle and can be something else for other databases. If you do not want to use this feature just don't specify the tag and it will use the default mechansm based on the primary key. snip ___ 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-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] Fast Updates Based on Row ID
So do you build all your other applications to use rowid? -Original Message- From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 1:59 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Well, We are an Oracle shop and woudl benefit [like loads of other Oracle users] from these changes. Remember they are there as an option. If you choose not to use them JAWS will work as usual. Vinay - Original Message - From: Jay Walters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 6:18 PM Subject: RE: [JBoss-dev] Fast Updates Based on Row ID This is oracle specific as far as I know (insert...returning...). The create problem needs to be addressed if one cannot retrieve the rowid, the logic needs to check and see if rowid is set or not - maybe Vinay already did this, I didn't look that hard. It's not clear to me what this will do for us. It is likely the index page will have been paged into the buffer cache to handle the initial query which returned the row so I don't see this saving a lot of disk i/o, just some cpu cycles. For example, depending on how one is creating the keys for new rows a better improvement might be to embed oracle specific code into the creation to query a sequence for the key. If there is a goal to really speed up Jaws when using Oracle or some other database we should probably really analyze what it's doing, unless somebody is already doing that. Cheers -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 12:59 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Will the 'returning column into ?' work in databases other than oracle? If not, that would be a problem: until JAWS is chainsawed (refactored to separate SQL syntax from the Command hierarchy), it'll be difficult to manage DB specific stuff at that level. Vinay's original patch isn't too bad, because it doesn't cause us to generate syntax that won't work elsewhere (you could give the name of a normal column as the rowid column and it would work (so long as that column is unique)) Jay Walters wrote: Use insert ... returning rowid into ? -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 12:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Hi, I may be wrong about oracle rowid changing on row update, it's been a couple of years. However interbase/firebird dbkey definitely does change on update, and I think someone mentioned the sql server analogue does too. In this situation, it seems to me that commit option A cannot be used, since to get a valid rowid, you have to read the db within the same transaction you are updating in. Also, even in Oracle, how can this be used with a newly inserted bean? create --inserts row in db later in same transaction, change values on this bean, the generated save has no rowid unless you fetched it in perhaps ejbpostcreate??? If you can fix this one, perhaps it can also be used to fetch values supplied by triggers on insert, such as sequence/generators used for abstract id. Am I wrong here? Could you explain in detail how this will work? Thanks david jencks On 2001.06.06 10:50:53 -0400 K.V. Vinay Menon wrote: The ROW ID bit does not touch ANY other portion in the JBoss source except for a) Generating SQLs b) Setting parameters. Options A,B and C should work as usual, correct me if I am wrong. As for option D, I am suprised that it has become part of our 'standard' commit options. I wrote some code and never had a chance to commit it and unless someone else has commited stuff for option D let me know and I'll have to commit the code! Vinay - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 2:40 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID Hi, This looks very interesting. I'm kind of too lazy to read your code to find out the answer for myself... My impression is that Oracle ROWID and similar facilities such as Interbase/firebird dbkey are stable only within a transaction, and in fact expected to change with any update. Could you please explain how your new feature guarantees updating the correct row with commit options A, B, C, and D? Thanks david jencks On 2001.06.06 08:56:02 -0400 K.V. Vinay Menon wrote: Hi Marc, When you were here in London we'd discussed adding functionality to use things like ROWID for fast updates and deletes [as opposed to using primary keys]. I have been able to implement this by 1. Adding a field in jaws.xml called rowid-column name. This is ROWID for Oracle and can be something else for other databases. If you do not want
RE: [JBoss-dev] Fast Updates Based on Row ID
If you do this then maybe you can extend the patch to include the insert...returning construct Just say you need Oracle8 to use this feature. Maybe you could also modify the SQL to not change the primary key field. I'll bet if you use a lot of referential integrity constraints this will speed things up more than the ROWID stuff. I thought Jaws was somehow setup using factories so one could just make a new set of modules for Oracle without too much pain. Sounds like this is not the case. How much work would it be to do this? Cheers -Original Message- From: danch To: [EMAIL PROTECTED] Sent: 6/7/01 1:32 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID K.V. Vinay Menon wrote: Dan Ch, Well as you might have noticed the code will work as usual if the rowid-column field is not specified in jaws.xml. If it is specified, it will then be used instead of the primary key. I am not sure of how other databases work with rowids which is why jaws will still default to normal behaviour. I think i'd rather have a flag on the JAWS entity to turn on 'oracle-tuned-updates' than just indicating the name of the rowid column. That way people will be less likely to turn it on for other databases. Do you think we are in a position to submit the source? I'd have rather sent the modified source files for peer review in case I have goofed up! And *then* committed changes. Do you have the time to spare? I think we've gotten a pretty good peer review already. However, with the insert issue and the change Georg points out later (detect empty rowIDValue and fall back on primary key) I think you should probably work those ideas into the code and post again. Are you on the JBossCMP mailing list? Perhaps we should move this discussion there. ___ 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] Jboss test - understand results
Is there any documentation on how to understand the output from the test module? I have a hard time making sense out of the output, things like tests numbered 90-105 or something and then it'll print out 9 tests 0 failures 2 errors. What does this mean? Other than perhaps I broke something and I need to fix it! Is there a document which shows what the output is supposed to be? I see the .xml files which seem to have exceptions in them. Is that the place to start trying to figure out what has gone wrong? Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
opengroup.org - looks to be $35 USD. Cheers -Original Message- From: Christian Riege [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 10:53 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug? hi, On Thu, May 31, 2001 at 12:05:10PM +1200, Toby Allsopp wrote: The JTA spec is all I have to go on. It refers to the X/Open XA spec, but that's not free. Free as in free beer or free speech? If it's free beer I would be willing to donate the spec to the JBoss project (well, depends on price, but ...). Any resources on the web of where I could acquire the X/Open XA Spec? Best regards, Christian -- Riege Software International GmbH Phone: +49 (2159) 91 48 - 0 Mollsfeld 10 Fax : +49 (2159) 91 48 - 11 40670 Meerbusch, Germany http://www.riege.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] EJB generation
Andreas, EJBDoclet fans, what tool do you use to generate the persistence code, or do you use CMP? Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] EJB generation
My thoughts are a bit scattered, but here's what I've got at the moment. I'm working on putting together a web page but it's a bit funky yet. It's at, http://www.akutan.org. I'll just include all the links and stuff here for you as well. The book to which I referred, Program Generators with Java and XML, was written by craig cleaveland, http://www.craigc.com. He's got some stuff on his site. Two tools that generate EJBs from XML files are ejbwizard, http://www.mousetech.com/EJBWizard.html and Percolator, http://www.percolator.org. In terms of template engines, Rickard Oberg wrote one which you can download from http://www.dreambean.com. I don't have any comparison information between Rickard's template stuff and Craig's, but off the top of my head Craig's looks superior because he's actually generating Java code from the templates whereas Rickard is interpreting the templates. That means Craig's stuff allows you to insert Java code into your templates if the language doesn't do what you need. Cheers -Original Message- From: James Cook To: [EMAIL PROTECTED] Sent: 5/17/01 9:04 PM Subject: RE: [JBoss-dev] EJB generation I am also interested in the topic of template engines, esp. those driven by XML models. Can you provide links to any of these opensource offerings? thanks, jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters -snip At this point I would say XSLT probably isn't the way I would do it again. There is a new book on Java, XML and Program Generators and the author has put a template engine which uses XPath for navigation of the input XML, but I think the language is better than XSLT. I don't have the url as somebody is borrowing my copy of the book right now. Other people have also made open source template engines available. -snip ___ 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] EJB generation
This is clearly feasible. I have been working on it for my company for the
last 8 months or so. We generate an entire wire frame application from a
high level UML class diagram using XMI XSLT. We generate EJBs, dependent
objects, database scripts, session facades, proxies (Sun Service Locator or
Business Delegate - can't remember their patterns), simple command line
clients and a full MVC CRUD implementation using JSP on top of Struts. The
output of the build process right now is a .war and a .jar which we just
deploy and we're on our way. We're just wrapping up a parallel effort to
generate .NET code in C# using the same technologies.
At this point I would say XSLT probably isn't the way I would do it again.
There is a new book on Java, XML and Program Generators and the author has
put a template engine which uses XPath for navigation of the input XML, but
I think the language is better than XSLT. I don't have the url as somebody
is borrowing my copy of the book right now. Other people have also made
open source template engines available.
We started off using all open source tools last summer, jboss when entity
beans didn't work. Argo/UML when it crashed half the time. Struts when it
was evolving rapidly. Things have come a long way. We've also added
support for several COTS modelling tools, app servers and databases to our
project.
I've written an article on some of what we did for Java Report, but I don't
know when they'll publish it. I'd be happy to share more directly if
you're interested.
We have been working management to try and open source the work we have done
to date, with little luck. Perhaps we should give another go as most of our
developers have been pulled off the development of our framework and onto
paying gigs.
Cheers
Jay
-Original Message-
From: Paul Hammond
To: [EMAIL PROTECTED]
Sent: 5/17/01 1:04 AM
Subject: [JBoss-dev] EJB generation
Hi,
I don't know if this is directly relevant to this mailing list, but I'd
like to know if it's something that maybe is being considered by the
JBoss team, or whether it has already been done before elsewhere and if
so where.
I think a lot and maybe most EJB in development at the datamodel level
could and should where possible be automated by defining it
declaratively in XML and then generating everything else from that. The
idea would be that you get all the base datamodel EJB code and tables
generated from some XML type datamodel description.
Now I realise that at present there is the likes of Castor providing XML
Schema to/from Java, and various tools allow you to generate Java/DDL
from UML like MagicDraw or Rational Rose, or save it in XMI format and
generate from there, but they don't seem to allow you to control what is
generated through template files for example. They all seem to generate
plain Java classes, whereas it would be nice to generate EJBs and in the
format you would like.
In addition to the description of the attributes, it would be desirable
to express the relationships between EJBs as can be done in XMI for
instance.
YOu also would probably want to generate dependent objects as normal
classes, not EJBs.
Once this the tables have been created, EJB base classes created, then
the business logic EJBs can inherit from this 'datalevel' EJBs and you
can update your model in XML and regenerate all the base classes/tables
without worrying about merging regenerated code and your business logic.
I'll give a small example to illustrate more precisely what I mean.
Lets say we have an entity EJB called Foo.
It has 3 attributes X Y Z of type String
So you would then get
public interface Foo extends javax.ejb.EJBObject
{
public String getX() throws RemoteException;
public void setX(String newX) throws RemoteException;
same for Y and Z..
}
public class BaseFooBean implements javax.ejb.EntityBean
{
private String X,Y,Z;
implementations of methods above
}
you would get the DDL to create the Foo table and perhaps stored
procedures etc, also maybe a default deployment XML file.
and finally
public class FooBean extends BaseFooBean
{
all your business logic methods you write here
}
Also probably a .bat or .sh script to run everything as a 'one button'
operation.
Of course it would get more involved with relationships, and I haven't
put in any base methods for finders,
creation, remove, load, store etc, just want to illustrate the simple
hierarchy.
The generated code would always work first time once it was generated
correctly the first time, match the tables, and save a lot of editing,
compiling and debugging time.
In addition for relationships you could generate lazy navigation of
those relationships etc, and your base classes and interfaces with
default finder methods, ejbLoad, ejbStore etc etc.
Is there anything like that at present and is it something that has ever
been considered by JBoss designers?
Any opinions on the pros and cons, feasibility
RE: [JBoss-dev] Option D - Take Two!
Is anybody else getting 10 copies/day of ths email or is it just me who is
so lucky?
cheers
-Original Message-
From: K.V. Vinay Menon
To: [EMAIL PROTECTED]
Sent: 5/11/01 6:24 PM
Subject: Re: [JBoss-dev] Option D - Take Two!
Marc,
What do we call the class? Do we want to put the refresh rate in
the
jboss.xml file? I'd rather see it there than in the jcml file. What do
you
think? Also, if we don't have the synchornized block we might have un
predictable results. Assuming that look ups and adds are pretty fast
operations on a set it might be better to keep the block synchronized.
Any thoughts?
Vinay
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 11, 2001 11:20 PM
Subject: RE: [JBoss-dev] Option D - Take Two!
Almost,
The name is misleading the ones that are in the map we know for sure
that
will be valid since the next interceptor will refresh it, so the name
of
the
Map is validContexts, and in fact they are NOT ctxToInvalidate.
|/**
| * Collection of context cache keys
| */
|protected HashSet ctxToInvalidate = new HashSet();
Change that to validCtx
|
|/**
| * The cache refresh rate
| */
|private static int REFRESH_RATE = 3;
We will need to have that REFRESH_RATE in the jcml files at some point
it
will enable us to set the rate at which we invalidate the cache.
|public void init()
|throws Exception
|{
| commitOption =
|container.getBeanMetaData().getContainerConfiguration().getCommitOption
();
|
| if(commitOption == ConfigurationMetaData.D_COMMIT_OPTION)
| {
| //Start Timer Task Now!
| new Timer().schedule(new
ForceSynchronization(),0,REFRESH_RATE);
|}
|}
|private void register(EntityEnterpriseContext ctx, Transaction
tx)
|{
|}
|
|private void deregister(EntityEnterpriseContext ctx)
|{
|}
These 2 are only needed in the sync refresh so no need to have the
methods
here at all.
|public Object invokeHome(MethodInvocation mi)
|throws Exception
|{
| return getNext().invokeHome(mi);
|
|}
|
|public Object invoke(MethodInvocation mi)
|throws Exception
|{
| if(commitOption == ConfigurationMetaData.D_COMMIT_OPTION)
| {
| EntityEnterpriseContext ctx =
|(EntityEnterpriseContext)mi.getEnterpriseContext();
|
| //In case the invalidator thread wakes up!
| synchronized(ctxToInvalidate)
| {
| //Check if already present?
| if(!this.ctxToInvalidate.contains(ctx.getCacheKey()))
| {
| //If not invalidate cache
| ctx.setValid(false);
| //and add to the set to make sure it is skipped next
time
| this.ctxToInvalidate.add(ctx.getCacheKey());
| }
| }
| }
I argued in the previous mail that we shouldn't synchronize this
lookup,
there is no need to do so. The worst that can happen is that we lookup
a
key
when someone is adding in another thread or we are clearing the cache.
My
guess is that it will return a false so that we will refresh the
state.
But maybe I am wrong, what happens if someone is doing a lookup and we
are
structurally modifying the map, does something horribly wrong happen?
We
should avoid synchronized constructs at all cost in our interceptors
because
it effectively makes a single point of passage.
marc
|
| return getNext().invoke(mi);
|}
|
|
|private class ForceSynchronization
|extends TimerTask
|{
| ForceSynchronization()
| {
| }
|
|public void run()
|{
| synchronized(ctxToInvalidate)
| {
| //Clear the set. Will force invalidation next time on.
| ctxToInvalidate.clear();
| }
|}
|}
|}
|
|
|
|
|- Original Message -
|From: marc fleury [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Sent: Friday, May 11, 2001 7:58 PM
|Subject: RE: [JBoss-dev] RE: Option D - Take One !
|
|
| |Marc,
| |
| |Will do over the weekend! Just had time today to give this a try!
[and
|that
| |too about 45 mins!]. But I'll see to it that I go thru the
material
and
|do
| |it the way you'd like to see it work!!
|
| Great... btw I forgot to welcome you and congratulate you for
taking
the
| courageous plunge of hacking the container interceptors for your
first
| server contribution.. that is definitely ballsy. I realize the
class
|wasn't
| lost at all since you have a firm grasp of the graph of flows,
|the plugins
| the JMX init and the invoke detyped mechanisms (you took the right
|decision
| for the interceptor).
|
| PLUG The training can turn all of you in container developers
/PLUG.
|So
| you go and get that algo right and lightweight and we put it in.
|
| regards
|
| marc
|
RE: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
The second call is ejbLoad() not ejbFindByPrimaryKey(). This is also known as the n+1 query problem. As to the fat key pattern on the server side, I'm not sure if it works with Jboss or not. I believe there was some discussion at some point that it wouldn't, but I could be mistaken.I believe you should be able to build your own cache within your BMP beans.Both Cocobase and Toplink cache the original query and I don't think they use the fatkey pattern. Cheers Jay -Original Message-From: Paul Hammond [mailto:[EMAIL PROTECTED]]Sent: Tuesday, May 15, 2001 5:15 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Avoiding big numbers of selects loading EJB cache Hi guys, Just new to this list and JBoss. My question centers around efficient loading of EJBs into JBoss's EJB cache. Normally if you have a finder method, findByXXXYYYZZZ etc, which returns an Enumeration of the EJBs in question, you have a corresponding ejbFindByXXXYYYZZZ method that returns an Enumeration of primary key objects for that particular EJB. My understanding is that the implementation of the findByXXXYYYZZZ method by the container will generally call findByPrimaryKey with the Primary key objects that are returned by ejbFindByXXXYYYZZ one by one to load each EJB if it's not already in the cache. This typically involves an individual select statement from the database etc for each EJB to be loaded. If the cache is empty on startup, and you have a finder method returning say 5000 objects, then that will generate 5000 individual selects to the database, not very efficient. I have seen a third party trading system done using BMP on WebLogic whereby initially they have to load up a portfolio of 100,000 trades to run a Risk report on them. Takes about 30 minutes plus to start it up. Not nice. Really what you want is one select statement to get all the relevant information. How do you fit that into the EJB container architecture though? I know O/R tools like TopLink can integrate with say WebLogic so that WebLogic uses TopLink as it's cache. TopLink does support I believe instantion of lots of objects with one query. So you can in effect quickly load the cache. Therefore the container will find all the objects for the primary key are already in the cache and won't call findByPrimaryKey, at least that is my understanding of it, please correct me if I'm wrong here. Now in relation to JBoss, and leaving aside JAWS for a moment because supposing I want to use BMP, how would I do this with JBoss if I didn't want to use a third party O/R tool. You don't want to break the container contract obviously but I can't see how you would avoid doing what the container would do. Here's the sequence of events I would see happening in this hypothetical ejbFindByXXX method Method findByXXX called. Delegated to ejbFindByXXX Select query to database. Iterate through results set. Get the primary key from each row Check if it's in the cache. If it is not, create a new EJB and populate it from the result set and insert it into the cache Regardless, add the EJB primary key to the enumeration Return the enumeration Now the container generated method would do pretty much the same thing, but will always find the EJB in the cache because we've put it there, and hence will never call findByPrimaryKey and generate loads of select statements. However we would be messing with the containers cache which is completely outside the contract and we would be duplicating what the container does ourselves, so it's not a satisfactory way of doing things. Is there a legit way of doing this, or is it simply not possible to avoid all those calls to findByPrimaryKey and the associated select statements. Would JAWS CMP do it efficiently? Regs, Paul
RE: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Maybe I understand less than I think. Are you all saying that the actual scenario is ejbFindByXXX ejbFindByPrimaryKey ejbLoad when the bean needs to be loaded from disk (2N+1) and ejbFindByXXX ejbFindByPrimaryKey (N+1) when the N objects are all already in the app servers cache? Cheers -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:47 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache Paul Hammond wrote: Hi guys, Just new to this list and JBoss. My question centers around efficient loading of EJBs into JBoss's EJB cache. Normally if you have a finder method, findByXXXYYYZZZ etc, which returns an Enumeration of the EJBs in question, you have a corresponding ejbFindByXXXYYYZZZ method that returns an Enumeration of primary key objects for that particular EJB. My understanding is that the implementation of the findByXXXYYYZZZ method by the container will generally call findByPrimaryKey with the Primary key objects that are returned by ejbFindByXXXYYYZZ one by one to load each EJB if it's not already in the cache. This typically involves an individual select statement from the database etc for each EJB to be loaded. Actually it can get even worse than that: the container's findByXXXYYYZZZ probably won't even call findByPrimaryKey itself, but will allow that to be deferred until such time as the bean is actually accessed. This is a more elegant implementation, since the bean will always have to be checked to see if its state needs loading - avoiding findByPrimaryKey in findByXXXYYYZZZ keeps the load and check in one place. Also, remember that the cache needs to be checked in there as well! If the cache is empty on startup, and you have a finder method returning say 5000 objects, then that will generate 5000 individual selects to the database, not very efficient. I have seen a third party trading system done using BMP on WebLogic whereby initially they have to load up a portfolio of 100,000 trades to run a Risk report on them. Takes about 30 minutes plus to start it up. Not nice. Reporting off of EJBs is probably not the best implementation choice at this point in specdom - you'll be much kinder on your servers if you report the old fashioned way. But yes, this will be very ugly with BMP, no matter what app server you're using. Really what you want is one select statement to get all the relevant information. How do you fit that into the EJB container architecture though? With BMP, you can only cheat. With CMP, the CMP engine can do it. I know O/R tools like TopLink can integrate with say WebLogic so that WebLogic uses TopLink as it's cache. TopLink does support I believe instantion of lots of objects with one query. So you can in effect quickly load the cache. Therefore the container will find all the objects for the primary key are already in the cache and won't call findByPrimaryKey, at least that is my understanding of it, please correct me if I'm wrong here. I'm not sure, but I think it's more likely that WebLogic + TopLink wind up with a two level cache. Now in relation to JBoss, and leaving aside JAWS for a moment because supposing I want to use BMP, how would I do this with JBoss if I didn't want to use a third party O/R tool. You don't want to break the container contract obviously but I can't see how you would avoid doing what the container would do. Here's the sequence of events I would see happening in this hypothetical ejbFindByXXX method Method findByXXX called. Delegated to ejbFindByXXX Select query to database. Iterate through results set. Get the primary key from each row Check if it's in the cache. If it is not, create a new EJB and populate it from the result set and insert it into the cache This you really can't do. The container must be allowed to control the lifecycle of EJB instances. Regardless, add the EJB primary key to the enumeration Return the enumeration Now the container generated method would do pretty much the same thing, but will always find the EJB in the cache because we've put it there, and hence will never call findByPrimaryKey and generate loads o select statements. However we would be messing with the containers cache which is completely outside the contract and we would be duplicating what the container does ourselves, so it's not a satisfactory way of doing things. Is there a legit way of doing this, or is it simply not possible to avoid all those calls to findByPrimaryKey and the associated select statements. See the 'fat-key' pattern on theserverside.com. WARNING: this may significantly degrade JBoss' cache performance! Do you use data access objects? If so, consider creating a static 'read-ahead buffer' in the data access
