[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/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 find 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 ejbFind 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 find 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 ejbFind 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/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
[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 find 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 ejbFind 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 find 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 ejbFind 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
[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 = (Met
[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
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 > > cadex/AcrossResp > java.lang.Long > > > > objectid > > objectid > > I did declare in jbosscmp-jdbc.xml without the > 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: jbosstest/src/main/org/jboss/test/ejbconf/beans/ejb ReadOnlyBean.java
User: jwalters
Date: 02/04/08 21:27:25
Modified:src/main/org/jboss/test/ejbconf/beans/ejb ReadOnlyBean.java
Log:
Managed to checkin and break the testsuite... runs properly on my machine now.
Revision ChangesPath
1.3 +1 -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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ReadOnlyBean.java 9 Apr 2002 04:06:39 - 1.2
+++ ReadOnlyBean.java 9 Apr 2002 04:27:25 - 1.3
@@ -11,8 +11,8 @@
import java.rmi.RemoteException;
+import javax.ejb.CreateException;
import javax.ejb.EntityBean;
-
import javax.ejb.EntityContext;
/**
@@ -61,7 +61,6 @@
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: 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] 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: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: 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: 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 @@
*
*
*
- * @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(
[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 Integer 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/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] 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 mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Daniel OConnor
-* @version $Revision: 1.33 $
+* @version $Revision: 1.34 $
* 2001219 marc fleury
*
* 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 @@ Install the JBoss Server 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. Create a NetBeans Project -Start NetBeans, I used NetBeans 3.2 while writing this howto. The first +Start 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 -> 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 -> 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. At this point you need to add any other jar files specific to your app which @@ -140,14 +142,6 @@ -Sprinkle breakpoints throughout your EJB and or Client Code - -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. - - - Start the JBoss server Start JBoss using the debug script which you previously created. Deploy the @@ -158,12 +152,18 @@ -Deploy the Beans +Sprinkle breakpoints throughout your EJB and or Client Code -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 be an artifact of the class loading +scheme used by JBoss, and a problem within NetBeans where it puts a breakpoint +on the system classloader when you just open the source file and toggle a +b
[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 @@ Jay Walters - [EMAIL PROTECTED] + [EMAIL PROTECTED] Purpose ___ 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 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 @@ Jay Walters - [EMAIL PROTECTED] + [EMAIL PROTECTED] Purpose ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/resource/cci Connection.java
User: jwalters Date: 01/10/02 19:09:06 Modified:src/main/javax/resource/cci Connection.java Log: Updated Connection interface to match 1.0 spec (removed get/setAutoCommit). Revision ChangesPath 1.2 +0 -10 jboss-j2ee/src/main/javax/resource/cci/Connection.java Index: Connection.java === RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/resource/cci/Connection.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Connection.java 2001/04/05 04:20:41 1.1 +++ Connection.java 2001/10/03 02:09:06 1.2 @@ -30,11 +30,6 @@ public Interaction createInteraction() throws ResourceException; /** - * Gets the current auto commit state for the connection. - */ -public boolean getAutoCommit() throws ResourceException; - -/** * Gets a LocalTransaction object which allows the client to manage * local transactions for the connection. */ @@ -51,9 +46,4 @@ * underlying resource for the connection. */ public ResultSetInfo getResultSetInfo() throws ResourceException; - -/** - * Sets the auto commit state for the connection. - */ -public void setAutoCommit( boolean autoCommit ) throws ResourceException; } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
If you use copy on write of the MBeans (and on the list of MBeans - the stack) then you can probably do everything needed. Of course this raises questions about what is the impact of multiple versions of a specific MBean is, but these are supposed to be stateless interceptor-like MBeans right, so it's not like you're making a new connection pool. I would think a simple copy on write approach would be the quickest to write, but it needs to be wrapped up so the code adding the new MBean doesn't have to remember to do the copy - it just happens. I imagine this is why the model of a database that just does it, is appealing. Cheers -Original Message- From: David Jencks To: jboss-dev Sent: 10/2/01 6:38 PM Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [[EMAIL PROTECTED]] (Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow "pre-completion" invocations complete with the old versions, whereas "post completion" invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: > Hi, > > I've been speculating about this in the context of bean > redeployment. > > Just creating a new configuration (or deployment) and atomically > switching over to it is not really enough: Old transactions that > have used the old configuration (or deployment) should continue > to use that, so the old configuration (or deployment) has to be > kept until all transactions that have ever used it have terminated. > > But to avoid service disruption, calls in the context of new > transactions that have not used the old configuration should be > using the new configuration at the same time as some old > transactions still use the old configuration. > > I agree that this can become very hairy. > > > Best Regards, > > Ole Husgaard. > > > David Jencks wrote: > > > > Don't panic marc, even I don't plan to implement this this week ;-) > > > > Here's the context I'm thinking about, and please note IANASA (I am not > a > > system administrator)... but if I were running the jboss cluster at > > Megacorp Conglomerates, I expect my audit trail requirements would > include > > knowing exactly what configuration was used to process each online b2b > soap > > enabled etc purchase order, yet allow on the fly hot updates to avoid > even > > momentary service disruptions. Also, you don't want half-completed > > configuration changes to start getting used - you want them to finish > > first. I'm just saying this point of view on requirements (if they are > > indeed desirable, I don't really know) is satisfied really well by the > > versioning transaction model of firebird/interbase: transactions get > > numbered as they come in, so you can tell from the log what order they > > happened in, and configuration changes are invisible to all > transactions > > (invocations) that start before the configuration change commits, > whereas > > those after the commit use the new configuration. Conceptually this > seems > > cleaner to me than the "valves" you were talking about to stop MIs > during > > reconfiguration. > > > > As Rickard says, this might have a lot of overhead, and at least some > of > > the properties of this system will come from careful use of copy on > write. > > [snip] > > ___ 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] 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|get&put)... --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] 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
[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] 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 >
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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JBOSS-SYSTEM:service=Naming > > JBOSS-SYSTEM:service=TransactionManager > > > > > > > > > > > > > > > > > >> name="DefaultDomain:service=ConnectionFactoryLoader,name=fooDS"> > > ConnectionURL=jdbc:mysql://loc alhost/foo > > DriverClass=org.gjt.mm.mysql.Driver > > UserName= > > fooDS > > java:/TransactionManager > > Minerva JDBC LocalTransaction > > ResourceAdapter > > JCA:service=RARDeployer > > MinervaSharedLocalCMFactory > > > > # > > #Wed Aug 15 16:17:29 EDT 2001 > > InvalidateOnError=false > > BlockingTimeoutMillis=50 > > IdleTimeoutMillis=180 > > MaxSize=10 > > TimestampUsed=false > > IdleTimeoutEnabled=false > > CleanupIntervalMillis=12 > > MinSize=0 > > GCMinIdleMillis=120 > > GCEnabled=false > > MaxIdleTimeoutPercent=1.0 > > > > > > org.jboss.resource.security.ManyToOnePrincipalMapping > > > > UserName= > > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-devel
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
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 (?1, ?2)
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] 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
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] 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 -> 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. ___ 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] jboss.jcml reading properties problem/bug.
Did you make this change to the mainline as well?
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 7:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Throwing away the new lines is not correct. The jboss.jcml file is an xml
file and it
does not have line oriented semantics. The change you propose to add in the
missing new line makes sense. I'll add it to the next beta release which
will come out tomorrow.
- Original Message -
From: "John Landers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 3:26 PM
Subject: [JBoss-dev] jboss.jcml reading properties problem/bug.
> I was working with jboss2.4 beta and now the code
> that reads this file strips out the cr/lf since it is using
> BufferedReader.readLine(). This works fine for most xml
> but for MBeans that use and attribute that contains multiple properties
> like this:
> name="JCA:service=ConnectionFactoryLoader,name=JmsXA">
>
> MinSize=0
> MaxSize=10
> Blocking=true
> GCEnabled=false
>
> It becomes a string with a single line of all the properties and the
> java.util.Properties::load only gets
> a single property.
>
> The problem is in
> org/jboss/configuration/ConfigurationService::loadConfiguration
> public void loadConfiguration() throws Exception {
> // The class loader used to kocal the configuration file
> ClassLoader loader =
Thread.currentThread().getContextClassLoader();
>
> // Load user config from XML, and create the MBeans
> InputStream input =
loader.getResourceAsStream(CONFIGURATION_FILE);
>
> StringBuffer sbufData = new StringBuffer();
> BufferedReader br = new BufferedReader(new
> InputStreamReader(input));
>
> String sTmp;
>
> try {
> while((sTmp = br.readLine())!=null){
>sbufData.append(sTmp);
> // need to append in the eol
> sbufData.append(System.getProperty("line.separator"));
> }
> } finally {
> input.close();
> }
>
> Does this sound correct or are properties used in this fashion not
supported
> anymore?
> Maybe it is already fixed.
>
> jcl.
>
> ___
> 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] CVS update: jboss/src/main/org/jboss/jdbc
I'm not sure what dependencies there might be between the latest jbosspool,jbosscx, jboss-j2ee and jboss mainline changes I made and you guys pushing a new jbosspool into 2.4. Ok, actually I'm worried something will be fouled up because of the dependencies between the various bits and pieces I touched. I did not tag anything prior to the changes I made (my very bad). Did you guys do anything with jbosscx in terms of the 2.4 branch? In the end it was really just support for pfd2 of the connector and we can push it all into 2.4, I was just working on the main branch. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 12:28 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/jdbc Also add a Rel_2_4_0_21 tag to the jbosspool module on the 2.4 branch to tie the module code to the binary jar with the same tag in the jboss module. The non-jboss cvs modules are not labeled independent of the jboss module, so every change on the 2.4 branch is a change to the jboss release. ___ 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] JBossCX use of Mbeans
Do I need an MBean for each connector which I'm deploying to JBossCX (maybe I'm really confused here)? It seems that this is how the two which are distributed with the standard JBoss release are configured. Is this how it works right now? Is there some reason that it needs to be this way? Cheers ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-442479 ] Connector MBean Config seems off
Looks like this might have changed when Vinay made a fix to buffer the jboss.jcml file so it could be read from a webserver. His change strips newlines from the file. Any objections to modifying it to put the newlines back in (literally) when we read the jboss.jcml file? It seems to work fine in my environment, just don't need to break the world if there is some reason not to do this. Cheers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 12:49 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-442479 ] Connector MBean Config seems off Bugs item #442479, was opened at 2001-07-18 09:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=442479&group_id= 22866 Category: JBossCX Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Jay Walters (jwalters) Assigned to: Nobody/Anonymous (nobody) Summary: Connector MBean Config seems off Initial Comment: I am playing around with the connector/jbosscx stuff in CVS main and I'm seeing that the properties aren't working right - carriage control appears to be removed from the attribute elements in the jboss.jcml file. This manifests itself where I'm setting the principal stuff as in - org.jboss.resource.security.ManyToOnePrincipalMapping userName=jay password=jay When the principal mapping properties get sent into the MBean for the connector they are "userName=jay password=jay" with no carriage control in there anymore. The connector mBean tries to load them into a properties object using Property.load() which requires carriage control between properties, so everything goes into the first value. Another place to see this is in the jboss-auto.jcml file where all the attributes for connectors get jumbled onto a single line. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=442479&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-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* )> - + - + @@ -437,8 +437,8 @@ standard information into the standard deployment descriptor. --> - - + + ___ 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/18 07:40:14 Modified:src/lib jbosscx.jar jbosspool.jar Log: Completed update of jbosscx to Connector 1.0 pfd2 spec. Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches Revision ChangesPath 1.4 +36 -29jboss/src/lib/jbosscx.jar <> 1.5 +96 -96jboss/src/lib/jbosspool.jar <> ___ 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 <> ___ 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 @@ java.lang.String java:DefaultJMSProvider - -basic-password + + BasicPassword javax.resource.security.PasswordCredential - + false ___ 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 @@ Driver java.lang.String - -basic-password + + BasicPassword javax.resource.security.PasswordCredential - + false ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/security ManyToOnePrincipalMapping.java
User: jwalters
Date: 01/07/18 07:36:05
Modified:src/main/org/jboss/resource/security
ManyToOnePrincipalMapping.java
Log:
Completed update to pfd2, more changes to DTD.
Thanks to Tomasz Skutnik [EMAIL PROTECTED] for the patches.
Revision ChangesPath
1.2 +3 -3
jbosscx/src/main/org/jboss/resource/security/ManyToOnePrincipalMapping.java
Index: ManyToOnePrincipalMapping.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/security/ManyToOnePrincipalMapping.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ManyToOnePrincipalMapping.java2001/02/06 06:54:41 1.1
+++ ManyToOnePrincipalMapping.java2001/07/18 14:36:05 1.2
@@ -30,7 +30,7 @@
*
* @see org.jboss.resource.ConnectionManagerImpl
* @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class ManyToOnePrincipalMapping
extends PrincipalMappingSupport
@@ -61,7 +61,7 @@
Subject subject = new Subject();
subject.getPrincipals().add(resourcePrincipal);
- if (metadata.getAuthMechType().equals("basic-password"))
+ if (metadata.getAuthMechType().equals("BasicPassword"))
{
// The spec says that we need a new instance of this every
// time, because it is specific to a managed connection
@@ -74,7 +74,7 @@
}
else
{
- throw new RuntimeException("Unsupported auth-mech-type: '" +
+ throw new RuntimeException("Unsupported authentication-mechanism-type: '" +
metadata.getAuthMechType() + "'");
}
___
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/lib jbosscx.jar
User: jwalters Date: 01/07/18 07:38:23 Modified:lib jbosscx.jar Log: Completed update of jbosscx to Connector 1.0 pfd2 Thanks to Thomasz Skutnik [EMAIL PROTECTED] for the patches. Revision ChangesPath 1.3 +36 -29jbosspool/lib/jbosscx.jar <> ___ 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: 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 <> 1.3 +17 -17jbosstest/src/lib/jboss-jdbc_ext.jar <> ___ 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 <> ___ 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 <> 1.4 +17 -17jbossmq/src/lib/jboss-jdbc_ext.jar <> ___ 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 <> 1.4 +96 -96jboss/src/lib/jbosspool.jar <> ___ 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 <> ___ 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 @@ org.jboss.jms.ra.JmsConnectionFactoryImp javax.jms.Session org.jboss.jms.ra.JmsSession -xa_transaction +XATransaction JmsProviderAdapterJNDI java.lang.String @@ -24,4 +24,4 @@ false - \ No newline at end of file + ___ 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/17 19:53:51
Modified:src/main/org/jboss/resource RARMetaData.java
Log:
Updated error message if bad transaction-support element supplied in
RAR deployment descriptor.
Revision ChangesPath
1.5 +4 -4 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.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RARMetaData.java 2001/07/18 02:29:44 1.4
+++ RARMetaData.java 2001/07/18 02:53:51 1.5
@@ -26,7 +26,7 @@
*
* @see RARDeployer
* @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class RARMetaData
// extends Y
@@ -284,9 +284,9 @@
else
throw new DeploymentException("Invalid transaction support '" +
s + "', it must be one of " +
- "'no_transaction', " +
- "'local_transaction' or " +
- "'xa_transaction'");
+ "'NoTransaction', " +
+ "'LocalTransaction' or " +
+ "'XATransaction'");
transactionSupport = ts;
}
___
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 <> ___ 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 @@ org.jboss.pool.connector.jdbc.JDBCDataSource java.sql.Connection org.jboss.pool.jdbc.ConnectionInPool -local_transaction +LocalTransaction The default user name used to create JDBC connections. ___ 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/17 19:29:44
Modified:src/main/org/jboss/resource RARMetaData.java
Log:
DTD change for transaction-support element for pfd2
Revision ChangesPath
1.4 +4 -4 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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- RARMetaData.java 2001/04/15 04:31:39 1.3
+++ RARMetaData.java 2001/07/18 02:29:44 1.4
@@ -26,7 +26,7 @@
*
* @see RARDeployer
* @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class RARMetaData
// extends Y
@@ -278,9 +278,9 @@
{
String s = getElementContent(element);
int ts;
- if (s.equals("no_transaction" )) ts = TX_SUPPORT_NO;
- else if (s.equals("local_transaction")) ts = TX_SUPPORT_LOCAL;
- else if (s.equals("xa_transaction" )) ts = TX_SUPPORT_XA;
+ if (s.equals("NoTransaction" )) ts = TX_SUPPORT_NO;
+ else if (s.equals("LocalTransaction")) ts = TX_SUPPORT_LOCAL;
+ else if (s.equals("XATransaction" )) ts = TX_SUPPORT_XA;
else
throw new DeploymentException("Invalid transaction support '" +
s + "', it must be one of " +
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/lib jboss-j2ee.jar jboss-jdbc_ext.jar
User: jwalters Date: 01/07/17 19:12:22 Modified:lib jboss-j2ee.jar jboss-jdbc_ext.jar Log: Updated j2ee jar files for connector pfd2 Revision ChangesPath 1.5 +126 -126 jbosspool/lib/jboss-j2ee.jar <> 1.3 +17 -17jbosspool/lib/jboss-jdbc_ext.jar <> ___ 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 <> ___ 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
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: [JBoss-dev] Reverse CMP?
I have done a lot of work generating EJBs from UML models, I am willing to share what I've learned if you are interested. Cheers -Original Message- From: Brian Gilman [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 3:01 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Reverse CMP? Hello, Does anyone know of an open source project which is doing anything akin to what cocobase does? ie. Automatically generating EJB's from databases? I have recently started a project to do just this but did not want to waste my efforts. Thanks! -Brian --- Brian Gilman <[EMAIL PROTECTED]> Sr. Software Engineer MIT/Whitehead Inst. Center for Genome Research One Kendall Square, Bldg. 300 / Cambridge, MA 02139-1561 USA phone +1 617 252 1069 / fax +1 617 252 1902 ___ 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] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
They are all case sensitive when it comes to the data...
-Original Message-
From: Vinay Menon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 8:59 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
finder SQL text
Dan,
Oracle case sensitive as well. One of the chaps here put a finder query
... "where flg='T'"
Obviously it didn't work cos the JDBCDefinedFinderCommand issued it to
the backed as "where flg=i't'". This is cos the where clause is constructed
with the lower case query. Do you want me to fix it?
Vinay
- Original Message -
From: "danch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 4:17 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
finder SQL text
> Does anybody know what databases are case sensitive WRT column and table
> names (or even keywords). I've never run into case sensitive SQL
> databases before.
>
> [EMAIL PROTECTED] wrote:
>
> > Bugs item #438115, was opened at 2001-07-02 19:50
> > You can respond by visiting:
> >
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=438115&group_id=
22866
> >
> > Category: JBossCMP
> > Group: v2.4 BETA (stable)
> > Status: Open
> > Resolution: None
> > Priority: 5
> > Submitted By: Michael Jara (mjara)
> > Assigned to: Nobody/Anonymous (nobody)
> > Summary: JAWS lower-cases custom finder SQL text
> >
> > Initial Comment:
> > JAWS is now lower-casing all custom finder SQL text
> > specified in jaws.xml. Most database drivers seem to
> > ignore case, but some (such as JConnect5.2/SybaseASE)
> > do not.
> >
> > For example, if I have this in my jaws.xml file:
> >
> >
> > EventDescription
> >
> > findByEventType
> > , TypeDescriptionPair,
> > EventType WHERE EventType.description={0} AND
> > EventType.enumerationIndex=TypeDescriptionPair.eventTyp
> > eKey AND
> > TypeDescriptionPair.eventDescriptionKey=EventDescriptio
> > n.enumerationIndex
> >
> > EventDescription.description
> >
> >
> >
> > All table and field names are lower-cased on
> > execution. This is the trace logged in Beta 2.4:
> >
> > 2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS - findByEventType command
> > executing: SELECT EventDescription.enumerationIndex,
> > EventDescription.description FROM EventDescription,
> > typedescriptionpair, eventtype where
> > eventtype.description=? and
> > eventtype.enumerationindex=typedescriptionpair.eventtyp
> > ekey and
> > typedescriptionpair.eventdescriptionkey=eventdescriptio
> > n.enumerationindex ORDER BY
> > EventDescription.description
> > 2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS - Set parameter: idx=1,
> > jdbcType=VARCHAR, value=Construction
> > 2001-07-02 20:39:22,285 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS -
> > com.sybase.jdbc2.jdbc.SybSQLException: The column
> > prefix 'eventdescription' does not match with a table
> > name or alias name used in the query. Either the table
> > is not specified in the FROM clause or it has a
> > correlation name which must be used instead.
> >
> > This DOES work properly in release 2.2 (maintaining
> > case as entered in jaws.xml.)
> >
> > --
> >
> > You can respond by visiting:
> >
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=438115&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] 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.
I 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.
> > > 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 fis
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 trans
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 > > > > > > > > > > > > __
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. > > > > > > > > > > > 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] 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
[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: 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. > 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
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: [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: 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: 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)
I don't edit my xml by hand or by tool, I generate it! -Original Message- From: Aaron Mulder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 10:14 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: > 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... That's a much different assertion than "there shoouldn't be a GUI". After all, people who understand the files need to edit them too. > It can be a checkbox on a feature list though and sometimes that is > important (even though it feels wrong!-) I disagree. While I can certainly edit XML by hand, it's not necessarily fun to unpack the JAR, edit the file, put it back in, try to deploy it, see what syntax errors I've made, unpack the JAR, edit the file... There are a couple of nice things about a GUI. It does all the validation for you, so you don't have to worry about syntax. It links up all the JBoss elements to the corresponding ejb-jar.xml elements so you don't have to worry about forgetting a single bean or cmp field or whatever. It gives you help on the individual elements, so if you forget what some specific obscure setting means, you don't have to look it up elsewhere. And it can make it really fast to convert from one EJB server to another. Why would you *want* to edit your XML by hand? 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: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
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!-) -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:27 PM To: [EMAIL PROTECTED] Subject: Re: The next generation GUI (was : Re: [JBoss-dev] EJX and XML) Dude, GUI tools suck. Just edit the xml by hand. IMO if a person can't edit xml they shouldn't be configuring the server or ejb-jar. -dain - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 2:42 PM Subject: 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 > ___ 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] 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: [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] 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 1209>javap -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 SystemException without detail message.
*/
public SystemException()
{
}
/** Constructs an SystemException with the specified
detail message.
@param msg the detail message.
*/
public SystemException(String msg)
{
super(msg);
}
/** Constructs an SystemException 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 1210>serialver -classpath j2ee.jar javax.transaction.SystemException
javax.transaction.SystemException:static final long serialVersionUID
= 839699079412719325L;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] lib/jboss-j2ee.jar vs. client/jboss-j2ee.jar
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] [ 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 e
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 /
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=detail&atid=376685&aid=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=detail&atid=376685&aid=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] CVS update: jboss/src/etc class.java interface.java
My IDE doesn't seem to support 'cowboy neal!' as an indent, is that some new Java thing? "how many spaces do you use in your identation 0(!) 1 2 3 4 1024 cowboy neal!" and I am pretty the majority of answers is "cowboy neal"... 2 spaces sounds great! ___ 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
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=detail&atid=376685&aid=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=detail&atid=376685&aid=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
RE: [JBoss-dev] No storeEntity before ejbFind
I'd have to say not only the manuals, but the big TP/database books stink on
this one. No where does it state that changes made within an ACID
transaction are visible within the transaction, and that ANSI isolation
levels effect other transactions. It implies this, but not clearly enough
for our friend.
Really, take our word for it, or try the program or SQL scripts I sent.
Otherwise give it a rest, we're not a bunch of yahoots.
Cheers
-Original Message-
From: Bill Burke
To: [EMAIL PROTECTED]
Sent: 6/15/01 7:49 PM
Subject: RE: [JBoss-dev] No storeEntity before ejbFind
Gina,
Why don't you bring up a SQL*PLUS window and try it yourself instead of
quoting Oracle manuals. My own experiments with SQL*PLUS and jdbc DO
NOT
verify your claims. BTW, I'm on Oracle 8.1.7. Maybe older versions
work
differently.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
Gina
> Hagg
> Sent: Friday, June 15, 2001 5:53 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before ejbFind
>
>
> and, this is from the same page as before.
> http://technet.oracle.com/doc/server.815/a67781/c23cnsis.htm#2570
>
> Oracle Isolation Levels
>
> Oracle provides three transaction isolation levels:
>
> read committed
> This is the default transaction isolation level. Each
> query executed by a transaction sees only data that
> was committed before the query (not the transaction)
> began. An Oracle query will never read dirty
> (uncommitted) data.
> Because Oracle does not prevent other transactions
> from modifying the data read by a query, that data may
> be changed by other transactions between two
> executions of the query. Thus, a transaction that
> executes a given query twice may experience both
> nonrepeatable read and phantoms.
>
> serializable transactions
> Serializable transactions see only those changes that
> were committed at the time the transaction began, plus
> those changes made by the transaction itself through
> INSERT, UPDATE, and DELETE statements. Serializable
> transactions do not experience nonrepeatable reads or
> phantoms.
>
> read-only
> Read-only transactions see only those changes that
> were committed at the time the transaction began and
> do not allow INSERT, UPDATE, and DELETE statements.
>
> --- Jay Walters <[EMAIL PROTECTED]> wrote:
> > 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() ) {
> >
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
RE: [JBoss-dev] No storeEntity before ejbFind
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
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] 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! ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] No storeEntity before ejbFind
You are still confused Gina, if you go into SQL*Plus and type the following
create table foo ( x varchar(32));
set autocommit off;
insert into foo values ('gina');
select * from foo;
you will see the value just inserted and you are in the middle of the
transaction. Rollback will clean out the table...
This has always been (V4-V8i) and will always be... otherwise how would
after triggers work for example. There is a freaky option in Oracle they
put in just to blow out the TPC-A benchmark, discrete transactions, that
doesn't let you read changes during the transaction.
Cheers
Jay
-Original Message-
From: Gina Hagg [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 1:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] No storeEntity before ejbFind
Sorry, I have been out for a while.
Just wanted to say that
Read committed is the default and was the only
automatic isolation level provided before Oracle
Release 7.3.
And Read committed is still the default which doesn't
let anybody even within the transaction see the
updated changes.
However, you are right, they added Serializable after
7.3 which you have to set up as the isolation level,
which allows you within a transaction see the changes
you have made.
And it is only in this mode that you can.
Of course, SQLPlus is Oracle specific which by the way
uses SQLNet and not some JDBC-ODBC driver, and has
serializable settings.
Oracle does advise Read Committed as isolation setting
, therefore i have rarely seen companies use anything
but that...
Sorry, if i caused confusion..
--- David Jencks <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Hey guys, think a minute. What transaction
> isolation means is _other_
> transactions can't see your work until you commit.
> Of course _your_
> transaction can see everything you've done. If
> you're working with say the
> oracle interactive interface and insert a record in
> a table, if you query
> the table you can see it right away, you don't have
> to commit first.
> _other_ people can't see it until you commit. This
> has nothing to do with
> xa or anything else.
>
> [although there is a related issue with "tightly
> coupled" and "loosely
> coupled" transaction branches in xa: loosely coupled
> means different
> branches of the same transaction can't see each
> others work. This should
> only arise when several transaction managers are
> using the same global
> transaction against the same resource, and the
> XAResources can't agree that
> they are using the same resource. Maybe this is
> what you guys are thinking
> of, but this should only be a potential problem with
> distributed jboss]
>
> I'm pretty sure someone else complained about this a
> couple of weeks ago,
> although I can't find the reference - they were
> modifying an entity, then
> doing a finder method returning a collection
> including the "just modified"
> bean, except they weren't seeing the modifications.
>
> In my opinion, if this requirement was not present
> in ejb 1.1, is was a
> serious requirements bug, encouraging logically
> inconsistent behaviour from
> the container.
>
> Thanks, Bill.
>
> david jencks
>
> On 2001.06.14 15:49:34 -0400 marc fleury wrote:
> > |I have been working with databases for a long
> time,
> > |and particularly with Oracle, I am not aware that
> this
> > |can happen, whether in transaction or not, before
> > |commit, nobody can see the updated table period
> in the
> > |database..
> >
> > well that is my point precisely, it seems to imply
> that the updates
> > "before
> > the commit" are seen by connections enrolled in
> the SAME transaction
> > THROUGH
> > THE DATABASE and frankly I am a bit
> skeptical as to the level of
> > support for these features in the db or even if
> they exist at all or are
> > just "wishful features" (heck they don't even
> support 2pc and xa
> > right)...
> >
> > so this smells of "teen spirit" to me... by
> requiring "inflight"
> > visibility
> > of the changed records they put a difficult
> requirement on the db drivers
> > and I don't see it working well.
> >
> > They could have just required lock steps, as in
> first commit the changes
> > (and the db can follow that semantic) and then
> issue your findBy as just
> > another query...
> >
> > I am no db expert (they are rare these days) but
> it strikes me as a
> > misguided requirement.
> >
> > Bill for example couldn't you get the same
> functionality with the
> > serialiazed commits? Is this functionality that
> you couldn't get
> > otherwise?
> > you are the first one to require this feature (and
> you are savvy enough
> > to
> > scratch your itch so that is cool but still I
> wonder...)
> >
> > but the REAL question is "is it true that you
> cannot see changed tables
> > from
> > a connection participating in the SAME transaction
> that changed it in the
> > first place?"
> >
> > regards
> >
> > marcf
> >
> > |
> > |I don't know much about XA, it having its own set
> of
> > |rules though.
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
He wants the update SQL to execute before the remove SQL? The commit isn't the issue, it's the order of operations. What does the spec say about when remove() needs to execute the SQL? My question would be, if the bean has been removed should the persistence manager still be trying to update it? I can understand that one might want to somehow consider side effects, such as a database trigger so maybe one can't optimize out the update. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] 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. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
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
