[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EjbModule.java
User: d_jencks
Date: 02/04/16 23:12:34
Modified:src/main/org/jboss/ejb Tag: Branch_3_0 EjbModule.java
Log:
removed my debug logging statements, oops
Revision ChangesPath
No revision
No revision
1.21.2.2 +1 -7 jboss/src/main/org/jboss/ejb/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EjbModule.java,v
retrieving revision 1.21.2.1
retrieving revision 1.21.2.2
diff -u -r1.21.2.1 -r1.21.2.2
--- EjbModule.java17 Apr 2002 05:36:18 - 1.21.2.1
+++ EjbModule.java17 Apr 2002 06:12:32 - 1.21.2.2
@@ -83,7 +83,7 @@
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
* @author mailto:[EMAIL PROTECTED]";>Adrian.Brock
- * @version $Revision: 1.21.2.1 $
+ * @version $Revision: 1.21.2.2 $
*
* @jmx:mbean extends="org.jboss.system.ServiceMBean"
*/
@@ -1064,18 +1064,13 @@
throws DeploymentException
{
String path = name.substring(0, name.indexOf('#'));
- log.info("path: " + path);
String ejbName = name.substring(name.indexOf('#') + 1);
- log.info("ejbName: " + ejbName);
String us = deploymentInfo.url.toString();
- log.info("us: " + us);
//remove our jar name
String ourPath = us.substring(0, us.lastIndexOf('/'));
- log.info("ourPath: " + ourPath);
for (StringTokenizer segments = new StringTokenizer(path, "/");
segments.hasMoreTokens(); )
{
String segment = segments.nextToken();
- log.info("segment: " + segment);
//kind of silly, but takes care of ../s1/s2/../s3/myjar.jar
if (segment.equals(".."))
{
@@ -1085,7 +1080,6 @@
{
ourPath += "/" + segment;
} // end of else
- log.info("ourPath: " + ourPath);
}
URL target = null;
try
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How are ejb-link relative refs really supposed to work?
On 2002.04.17 01:41:27 -0400 David Jencks wrote: > OK, thanks, I implemented it that way. > > relative ejb-links now work (at least the testcase does;-) Well at least it works the first time the ejb-link test is run by itself. After that there are classcastexceptions !?!? I don't think these are link problems though! david jencks > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EjbModule.java
User: d_jencks
Date: 02/04/16 23:19:52
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
removed my debug logging statements, oops
Revision ChangesPath
1.23 +1 -7 jboss/src/main/org/jboss/ejb/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EjbModule.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- EjbModule.java17 Apr 2002 05:40:07 - 1.22
+++ EjbModule.java17 Apr 2002 06:19:52 - 1.23
@@ -83,7 +83,7 @@
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
* @author mailto:[EMAIL PROTECTED]";>Adrian.Brock
- * @version $Revision: 1.22 $
+ * @version $Revision: 1.23 $
*
* @jmx:mbean extends="org.jboss.system.ServiceMBean"
*/
@@ -1064,18 +1064,13 @@
throws DeploymentException
{
String path = name.substring(0, name.indexOf('#'));
- log.info("path: " + path);
String ejbName = name.substring(name.indexOf('#') + 1);
- log.info("ejbName: " + ejbName);
String us = deploymentInfo.url.toString();
- log.info("us: " + us);
//remove our jar name
String ourPath = us.substring(0, us.lastIndexOf('/'));
- log.info("ourPath: " + ourPath);
for (StringTokenizer segments = new StringTokenizer(path, "/");
segments.hasMoreTokens(); )
{
String segment = segments.nextToken();
- log.info("segment: " + segment);
//kind of silly, but takes care of ../s1/s2/../s3/myjar.jar
if (segment.equals(".."))
{
@@ -1085,7 +1080,6 @@
{
ourPath += "/" + segment;
} // end of else
- log.info("ourPath: " + ourPath);
}
URL target = null;
try
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 532 Errors:27 Failures: 4 [time of test: 17 April 2002 7:21 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin banktest.bat dbtest.sh locktest.bat mq-test.bat readaheadtest.sh banktest.sh hellotest.bat locktest.sh mq-test.sh testbeantest.bat bmptest.sh hellotest.sh longtest.sh perfcreate.bat testbeantest.sh ctstest.bat jmsratest.sh mdbtest.bat perfcreate.sh xatest.sh ctstest.sh jmx-test.sh mdbtest.sh perftest.bat load.bat mq-perf.bat perftest.sh dbtest.bat load.sh mq-perf.sh readaheadtest.bat
User: d_jencks Date: 02/04/16 22:57:41 Removed: src/bin banktest.bat dbtest.sh locktest.bat mq-test.bat readaheadtest.sh banktest.sh hellotest.bat locktest.sh mq-test.sh testbeantest.bat bmptest.sh hellotest.sh longtest.sh perfcreate.bat testbeantest.sh ctstest.bat jmsratest.sh mdbtest.bat perfcreate.sh xatest.sh ctstest.sh jmx-test.sh mdbtest.sh perftest.bat load.bat mq-perf.bat perftest.sh dbtest.bat load.sh mq-perf.sh readaheadtest.bat Log: removed obsolete test running scripts ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin banktest.bat dbtest.sh locktest.bat mq-test.bat readaheadtest.sh banktest.sh hellotest.bat locktest.sh mq-test.sh testbeantest.bat bmptest.sh hellotest.sh longtest.sh perfcreate.bat testbeantest.sh ctstest.bat jmsratest.sh mdbtest.bat perfcreate.sh xatest.sh ctstest.sh jmx-test.sh mdbtest.sh perftest.bat load.bat mq-perf.bat perftest.sh dbtest.bat load.sh mq-perf.sh readaheadtest.bat
User: d_jencks Date: 02/04/16 22:58:59 Removed: src/bin Tag: Branch_3_0 banktest.bat dbtest.sh locktest.bat mq-test.bat readaheadtest.sh banktest.sh hellotest.bat locktest.sh mq-test.sh testbeantest.bat bmptest.sh hellotest.sh longtest.sh perfcreate.bat testbeantest.sh ctstest.bat jmsratest.sh mdbtest.bat perfcreate.sh xatest.sh ctstest.sh jmx-test.sh mdbtest.sh perftest.bat load.bat mq-perf.bat perftest.sh dbtest.bat load.sh mq-perf.sh readaheadtest.bat Log: removed obsolete test running scripts ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/ear/b/META-INF ejb-jar.xml
User: d_jencks Date: 02/04/16 22:40:07 Modified:src/resources/naming/ear/b/META-INF ejb-jar.xml Log: implemented relative ejb-link (merged from Branch_3_0) Revision ChangesPath 1.3 +2 -2 jbosstest/src/resources/naming/ear/b/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/ear/b/META-INF/ejb-jar.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-jar.xml 23 Mar 2002 21:11:04 - 1.2 +++ ejb-jar.xml 17 Apr 2002 05:40:07 - 1.3 @@ -29,14 +29,14 @@ Session org.jboss.test.naming.interfaces.TestEjbLinkHome org.jboss.test.naming.interfaces.TestEjbLink -../subdir/naminga.jar#SessionA +subdir/naminga.jar#SessionA ejb/LocalRelativeSessionA Session org.jboss.test.naming.interfaces.TestEjbLinkLocalHome org.jboss.test.naming.interfaces.TestEjbLinkLocal -../subdir/naminga.jar#SessionA +subdir/naminga.jar#SessionA ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EjbModule.java
User: d_jencks
Date: 02/04/16 22:36:18
Modified:src/main/org/jboss/ejb Tag: Branch_3_0 EjbModule.java
Log:
implemented relative ejb-link
Revision ChangesPath
No revision
No revision
1.21.2.1 +99 -30jboss/src/main/org/jboss/ejb/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EjbModule.java,v
retrieving revision 1.21
retrieving revision 1.21.2.1
diff -u -r1.21 -r1.21.2.1
--- EjbModule.java15 Apr 2002 02:48:53 - 1.21
+++ EjbModule.java17 Apr 2002 05:36:18 - 1.21.2.1
@@ -8,6 +8,10 @@
+
+
+
+//import org.jboss.system.UnifiedClassLoader;
import java.lang.reflect.Constructor;
import java.net.MalformedURLException;
import java.net.URL;
@@ -20,12 +24,16 @@
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
+import java.util.StringTokenizer;
import javax.ejb.EJBLocalHome;
-import javax.naming.InitialContext;
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+import javax.transaction.TransactionManager;
import org.jboss.deployment.DeploymentException;
import org.jboss.deployment.DeploymentInfo;
+import org.jboss.deployment.MainDeployerMBean;
import org.jboss.ejb.BeanLockManager;
import org.jboss.ejb.Container;
import org.jboss.ejb.plugins.AbstractInstanceCache;
@@ -43,27 +51,21 @@
import org.jboss.metadata.SessionMetaData;
import org.jboss.metadata.XmlFileLoader;
import org.jboss.metadata.XmlLoadable;
+import org.jboss.mx.loading.UnifiedClassLoader;
import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.system.Service;
import org.jboss.system.ServiceControllerMBean;
import org.jboss.system.ServiceMBeanSupport;
-//import org.jboss.system.UnifiedClassLoader;
-import org.jboss.mx.loading.UnifiedClassLoader;
import org.jboss.util.jmx.MBeanProxy;
+import org.jboss.util.jmx.ObjectNameFactory;
import org.jboss.verifier.BeanVerifier;
import org.jboss.verifier.event.VerificationEvent;
import org.jboss.verifier.event.VerificationListener;
import org.jboss.web.WebClassLoader;
import org.jboss.web.WebServiceMBean;
-
import org.w3c.dom.Element;
-import javax.naming.NamingException;
-import javax.transaction.TransactionManager;
-
-import org.jboss.util.jmx.ObjectNameFactory;
-
/**
* An EjbModule represents a collection of beans that are deployed as a
* unit.
@@ -81,7 +83,7 @@
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
* @author mailto:[EMAIL PROTECTED]";>Adrian.Brock
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.21.2.1 $
*
* @jmx:mbean extends="org.jboss.system.ServiceMBean"
*/
@@ -136,11 +138,11 @@
private final Map moduleData =
Collections.synchronizedMap(new HashMap());
- //private MBeanServer server;
-
// Static
- /** Stores a map of DeploymentInfos to EjbModules. */
+ /** Stores a map of DeploymentInfos to EjbModules.
+* @todo this is silly, do something else.
+*/
private static HashMap ejbModulesByDeploymentInfo = new HashMap();
// Public
@@ -261,12 +263,21 @@
* not found
*/
public Container findContainer(String name)
+ throws DeploymentException
{
// Quick check
Container result = (Container)containers.get(name);
if (result != null)
+ {
+ //It is in this module
return result;
-
+ }
+ // Does the name include a path?
+ if (name.indexOf('#') != -1)
+ {
+ return locateContainerByPath(name);
+ } // end of if ()
+
// Ok, we have to walk the tree
return locateContainer(name);
}
@@ -995,10 +1006,6 @@
*/
private Container locateContainer(String name)
{
- // Check for a relative path
- if (name.startsWith(".."))
- return locateContainerRelative(name);
-
// Get the top level deployment
DeploymentInfo info = deploymentInfo;
while (info.parent != null)
@@ -1021,25 +1028,21 @@
*/
private Container locateContainer(DeploymentInfo info, String name)
{
- Container result = null;
-
// Try the current EjbModule
- EjbModule module = (EjbModule) ejbModulesByDeploymentInfo.get(info);
- if (module != null)
+ Container result = getContainerByDeploymentInfo(info, name);
+
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment DeploymentInfo.java
User: d_jencks
Date: 02/04/16 22:36:19
Modified:src/main/org/jboss/deployment Tag: Branch_3_0
DeploymentInfo.java
Log:
implemented relative ejb-link
Revision ChangesPath
No revision
No revision
1.5.2.1 +1 -4 jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java
Index: DeploymentInfo.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- DeploymentInfo.java 15 Apr 2002 02:48:53 - 1.5
+++ DeploymentInfo.java 17 Apr 2002 05:36:18 - 1.5.2.1
@@ -57,7 +57,7 @@
* @author mailto:[EMAIL PROTECTED]";>Daniel Schulze
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.5.2.1 $
*
* @todo implement type-safe enum for status.
*
@@ -78,8 +78,6 @@
//public static final ObjectName DEFAULT_LOADER_REPOSITORY =
ServiceController.DEFAULT_LOADER_REPOSITORY;
// Variables
- public static HashMap deployments = new HashMap();
-
/** when **/
public Date date = new Date();
@@ -233,7 +231,6 @@
{
if (!isXML)
{
- //ServiceLibraries.getLibraries().removeClassLoader((UnifiedClassLoader)
ucl);
((UnifiedClassLoader)ucl).unregister();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/ear/META-INF application.xml
User: d_jencks Date: 02/04/16 22:43:03 Modified:src/resources/naming/ear/META-INF application.xml Log: fixed path to naminga.jar (merge from Branch_3_0) Revision ChangesPath 1.2 +1 -1 jbosstest/src/resources/naming/ear/META-INF/application.xml Index: application.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/ear/META-INF/application.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- application.xml 17 Mar 2002 12:56:29 - 1.1 +++ application.xml 17 Apr 2002 05:43:03 - 1.2 @@ -4,7 +4,7 @@ naming ear test - naminga.jar + subdir/naminga.jar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How are ejb-link relative refs really supposed to work?
OK, thanks, I implemented it that way.
relative ejb-links now work (at least the testcase does;-)
david jencks
On 2002.04.17 00:49:44 -0400 Scott M Stark wrote:
> Its a path relative to the codebase of the referring and I interpret
> the example to imply the first case you mention. I base this on
> the behavior of the URL(URL, String) ctor behavior. Consider
> an ear with two jars j1.jar, j2.jar:
>
> e1.ear/
> --- j1.jar
> --- j2.jar
>
> j1.jar contains class C1, j2.jar contains class C2. Look at the behavior
> of this program that obtains the location of the C1 class and then
> forms the location of the C2 class based on the C1 codebase and
> the two relative possible relative paths to C2("./j2.jar" and
> "../j2.jar"):
>
> import java.net.URL;
>
> class tstRelativeURL
> {
>public static void main(String[] args) throws Exception
>{
> Class c1 = Class.forName("C1");
> URL c1URL = c1.getProtectionDomain().getCodeSource().getLocation();
> System.out.println("C1 location: "+c1URL);
> URL c2URL = new URL(c1URL, "./j2.jar");
> System.out.println("C2 location: "+c2URL);
> URL c22URL = new URL(c1URL, "../j2.jar");
> System.out.println("C22 location: "+c22URL);
>}
> }
>
> Java 1126>java -cp ".;j1.jar" tstRelativeURL
> C1 location: file:/D:/tmp/Java/j1.jar
> C2 location: file:/D:/tmp/Java/j2.jar
> C22 location: file:/D:/tmp/j2.jar
>
> Only the "./j2.jar" path results in a correct codebase from which C2 can
> be
> loaded.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: "jboss-dev" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 16, 2002 9:11 PM
> Subject: [JBoss-dev] How are ejb-link relative refs really supposed to
> work?
>
>
> > IMO the j2ee spec does not clearly define the meaning of relative
> ejb-link
> > elements. It gives and example of
> >
> > ../products/product.jar#ProductEJB
> >
> > What does the .. mean?
> >
> > I think it refers to this situation:
> >
> > accounting/accounting.jar (the ejb-jar.xml snippet above comes from
> this)
> > products/products.jar (contains ProductEJB)
> >
> > However it could also refer to this:
> >
> > accounting.jar (the ejb-jar.xml snippet above comes from this)
> > products/products.jar (contains ProductEJB)
> >
> > where the .. refers to getting out of the current jar.
> >
> > Ed Roman's book seems to mindlessly quote the spec without any
> additional
> > info whatsoever.
> >
> > Any other opinions? Experience with other app servers?
> >
> > thanks
> > david jencks
> >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EjbModule.java
User: d_jencks
Date: 02/04/16 22:40:07
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
implemented relative ejb-link (merged from Branch_3_0)
Revision ChangesPath
1.22 +99 -30jboss/src/main/org/jboss/ejb/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EjbModule.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- EjbModule.java15 Apr 2002 02:48:53 - 1.21
+++ EjbModule.java17 Apr 2002 05:40:07 - 1.22
@@ -8,6 +8,10 @@
+
+
+
+//import org.jboss.system.UnifiedClassLoader;
import java.lang.reflect.Constructor;
import java.net.MalformedURLException;
import java.net.URL;
@@ -20,12 +24,16 @@
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
+import java.util.StringTokenizer;
import javax.ejb.EJBLocalHome;
-import javax.naming.InitialContext;
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+import javax.transaction.TransactionManager;
import org.jboss.deployment.DeploymentException;
import org.jboss.deployment.DeploymentInfo;
+import org.jboss.deployment.MainDeployerMBean;
import org.jboss.ejb.BeanLockManager;
import org.jboss.ejb.Container;
import org.jboss.ejb.plugins.AbstractInstanceCache;
@@ -43,27 +51,21 @@
import org.jboss.metadata.SessionMetaData;
import org.jboss.metadata.XmlFileLoader;
import org.jboss.metadata.XmlLoadable;
+import org.jboss.mx.loading.UnifiedClassLoader;
import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.system.Service;
import org.jboss.system.ServiceControllerMBean;
import org.jboss.system.ServiceMBeanSupport;
-//import org.jboss.system.UnifiedClassLoader;
-import org.jboss.mx.loading.UnifiedClassLoader;
import org.jboss.util.jmx.MBeanProxy;
+import org.jboss.util.jmx.ObjectNameFactory;
import org.jboss.verifier.BeanVerifier;
import org.jboss.verifier.event.VerificationEvent;
import org.jboss.verifier.event.VerificationListener;
import org.jboss.web.WebClassLoader;
import org.jboss.web.WebServiceMBean;
-
import org.w3c.dom.Element;
-import javax.naming.NamingException;
-import javax.transaction.TransactionManager;
-
-import org.jboss.util.jmx.ObjectNameFactory;
-
/**
* An EjbModule represents a collection of beans that are deployed as a
* unit.
@@ -81,7 +83,7 @@
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
* @author mailto:[EMAIL PROTECTED]";>Adrian.Brock
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.22 $
*
* @jmx:mbean extends="org.jboss.system.ServiceMBean"
*/
@@ -136,11 +138,11 @@
private final Map moduleData =
Collections.synchronizedMap(new HashMap());
- //private MBeanServer server;
-
// Static
- /** Stores a map of DeploymentInfos to EjbModules. */
+ /** Stores a map of DeploymentInfos to EjbModules.
+* @todo this is silly, do something else.
+*/
private static HashMap ejbModulesByDeploymentInfo = new HashMap();
// Public
@@ -261,12 +263,21 @@
* not found
*/
public Container findContainer(String name)
+ throws DeploymentException
{
// Quick check
Container result = (Container)containers.get(name);
if (result != null)
+ {
+ //It is in this module
return result;
-
+ }
+ // Does the name include a path?
+ if (name.indexOf('#') != -1)
+ {
+ return locateContainerByPath(name);
+ } // end of if ()
+
// Ok, we have to walk the tree
return locateContainer(name);
}
@@ -995,10 +1006,6 @@
*/
private Container locateContainer(String name)
{
- // Check for a relative path
- if (name.startsWith(".."))
- return locateContainerRelative(name);
-
// Get the top level deployment
DeploymentInfo info = deploymentInfo;
while (info.parent != null)
@@ -1021,25 +1028,21 @@
*/
private Container locateContainer(DeploymentInfo info, String name)
{
- Container result = null;
-
// Try the current EjbModule
- EjbModule module = (EjbModule) ejbModulesByDeploymentInfo.get(info);
- if (module != null)
+ Container result = getContainerByDeploymentInfo(info, name);
+ if (result != null)
{
- result = module.getContainer(name)
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment DeploymentInfo.java
User: d_jencks
Date: 02/04/16 22:40:07
Modified:src/main/org/jboss/deployment DeploymentInfo.java
Log:
implemented relative ejb-link (merged from Branch_3_0)
Revision ChangesPath
1.6 +1 -4 jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java
Index: DeploymentInfo.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DeploymentInfo.java 15 Apr 2002 02:48:53 - 1.5
+++ DeploymentInfo.java 17 Apr 2002 05:40:07 - 1.6
@@ -57,7 +57,7 @@
* @author mailto:[EMAIL PROTECTED]";>Daniel Schulze
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*
* @todo implement type-safe enum for status.
*
@@ -78,8 +78,6 @@
//public static final ObjectName DEFAULT_LOADER_REPOSITORY =
ServiceController.DEFAULT_LOADER_REPOSITORY;
// Variables
- public static HashMap deployments = new HashMap();
-
/** when **/
public Date date = new Date();
@@ -233,7 +231,6 @@
{
if (!isXML)
{
- //ServiceLibraries.getLibraries().removeClassLoader((UnifiedClassLoader)
ucl);
((UnifiedClassLoader)ucl).unregister();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/ear/b/META-INF ejb-jar.xml
User: d_jencks Date: 02/04/16 22:36:19 Modified:src/resources/naming/ear/b/META-INF Tag: Branch_3_0 ejb-jar.xml Log: implemented relative ejb-link Revision ChangesPath No revision No revision 1.2.2.1 +2 -2 jbosstest/src/resources/naming/ear/b/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/ear/b/META-INF/ejb-jar.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- ejb-jar.xml 23 Mar 2002 21:11:04 - 1.2 +++ ejb-jar.xml 17 Apr 2002 05:36:19 - 1.2.2.1 @@ -29,14 +29,14 @@ Session org.jboss.test.naming.interfaces.TestEjbLinkHome org.jboss.test.naming.interfaces.TestEjbLink -../subdir/naminga.jar#SessionA +subdir/naminga.jar#SessionA ejb/LocalRelativeSessionA Session org.jboss.test.naming.interfaces.TestEjbLinkLocalHome org.jboss.test.naming.interfaces.TestEjbLinkLocal -../subdir/naminga.jar#SessionA +subdir/naminga.jar#SessionA ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 536 Errors:21 Failures: 6 [time of test: 17 April 2002 6:23 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/banknew/test BankMarathonTestCase.java BankStressTestCase.java
User: schaefera
Date: 02/04/16 22:07:24
Modified:src/main/org/jboss/test/banknew/test Tag: Branch_2_4
BankMarathonTestCase.java BankStressTestCase.java
Log:
Redesigned the banknew example therefore to a create separation between
the Entity Bean (CMP) and the Session Beans (Business Logic).
The test cases are redesigned but not finished yet.
Revision ChangesPath
No revision
No revision
1.1.2.3 +251 -436
jbosstest/src/main/org/jboss/test/banknew/test/Attic/BankMarathonTestCase.java
Index: BankMarathonTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/banknew/test/Attic/BankMarathonTestCase.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- BankMarathonTestCase.java 15 Apr 2002 04:28:15 - 1.1.2.2
+++ BankMarathonTestCase.java 17 Apr 2002 05:07:24 - 1.1.2.3
@@ -4,24 +4,29 @@
*/
package org.jboss.test.banknew.test;
-import java.util.*;
-import java.lang.reflect.*;
-import javax.ejb.*;
-import javax.naming.*;
-import javax.management.*;
-import org.jboss.test.banknew.ejbeans.AccountBean;
-import org.jboss.test.banknew.ejbeans.BankBean;
-import org.jboss.test.banknew.ejbeans.CustomerBean;
-import org.jboss.test.banknew.ejbeans.TellerBean;
-import org.jboss.test.banknew.interfaces.Account;
+import java.rmi.RemoteException;
+import java.util.Collection;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Random;
+
+import javax.ejb.CreateException;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+
import org.jboss.test.banknew.interfaces.AccountData;
-import org.jboss.test.banknew.interfaces.AccountHome;
-import org.jboss.test.banknew.interfaces.Bank;
-import org.jboss.test.banknew.interfaces.BankHome;
-import org.jboss.test.banknew.interfaces.Customer;
-import org.jboss.test.banknew.interfaces.CustomerHome;
-import org.jboss.test.banknew.interfaces.Teller;
-import org.jboss.test.banknew.interfaces.TellerHome;
+import org.jboss.test.banknew.interfaces.AccountSession;
+import org.jboss.test.banknew.interfaces.AccountSessionHome;
+import org.jboss.test.banknew.interfaces.BankData;
+import org.jboss.test.banknew.interfaces.BankSession;
+import org.jboss.test.banknew.interfaces.BankSessionHome;
+import org.jboss.test.banknew.interfaces.Constants;
+import org.jboss.test.banknew.interfaces.CustomerData;
+import org.jboss.test.banknew.interfaces.CustomerSession;
+import org.jboss.test.banknew.interfaces.CustomerSessionHome;
+import org.jboss.test.banknew.interfaces.TellerSession;
+import org.jboss.test.banknew.interfaces.TellerSessionHome;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -32,226 +37,154 @@
import org.apache.log4j.Category;
/**
- *
- * @see
- * @author Author: d_jencks among many others
- * @version $Revision: 1.1.2.2 $
+ * Marathon test case to test JBoss under moderate utilization for
+ * a long time (hours or days) to see if there is a memory leak or
+ * other long time exceptions
+ *
+ * @see
+ * @author Author: Andreas Schaefer
+ * @version $Revision: 1.1.2.3 $
*/
public class BankMarathonTestCase
extends JBossTestCase
{
// Constants -
- public static final int DEFAULT_DURATION = 1 * 60 * 60 * 1000;// 1 hour
+ public static final int DEFAULT_DURATION = Constants.ONE_DAY;// 1 Day (24
hours)
// Attributes
private int mIndex = 1;
private int mCount;
private Exception mException;
private boolean mExit = false;
+ private Context mContext;
+ private final Object mLock = new Object();
// Static
// Constructors --
- public BankMarathonTestCase(String name)
- {
- super(name);
- System.out.println( "AS BankMarathonTestCase(), name: " + name );
+ public BankMarathonTestCase( String pName ) {
+ super( pName );
+ System.out.println( "AS BankMarathonTestCase(), name: " + pName );
}
// Public
- public void testTeller()
- throws Exception
- {
- System.out.println( "AS testTeller()" );
- TellerHome home = (TellerHome)new InitialContext().lookup(
TellerBean.JNDI_NAME );
- Teller teller = home.create();
-
- BankHome bankHome = (BankHome)new InitialContext().lookup( BankBean.JNDI_NAME
);
-
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/banknew/ejbeans AccountSessionBean.java BankSessionBean.java CustomerSessionBean.java TellerSessionBean.java TransactionBean.java AccountBean.java BankBean.java CustomerBean.java TellerBean.java
User: schaefera
Date: 02/04/16 22:07:24
Modified:src/main/org/jboss/test/banknew/ejbeans Tag: Branch_2_4
AccountBean.java BankBean.java CustomerBean.java
Added: src/main/org/jboss/test/banknew/ejbeans Tag: Branch_2_4
AccountSessionBean.java BankSessionBean.java
CustomerSessionBean.java TellerSessionBean.java
TransactionBean.java
Removed: src/main/org/jboss/test/banknew/ejbeans Tag: Branch_2_4
TellerBean.java
Log:
Redesigned the banknew example therefore to a create separation between
the Entity Bean (CMP) and the Session Beans (Business Logic).
The test cases are redesigned but not finished yet.
Revision ChangesPath
No revision
No revision
1.1.2.3 +40 -73
jbosstest/src/main/org/jboss/test/banknew/ejbeans/Attic/AccountBean.java
Index: AccountBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/banknew/ejbeans/Attic/AccountBean.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- AccountBean.java 15 Apr 2002 04:28:15 - 1.1.2.2
+++ AccountBean.java 17 Apr 2002 05:07:24 - 1.1.2.3
@@ -10,13 +10,13 @@
import org.jboss.test.util.ejb.EntitySupport;
import org.jboss.test.banknew.interfaces.AccountData;
-// import org.jboss.test.banknew.interfaces.Customer;
+import org.jboss.test.banknew.interfaces.AccountPK;
/**
* The Entity bean represents a bank account
*
* @author Andreas Schaefer
- * @version $Revision: 1.1.2.2 $
+ * @version $Revision: 1.1.2.3 $
*
* @ejb:bean name="bank/Account"
* display-name="Bank Account Entity"
@@ -31,16 +31,21 @@
*
* @ejb:transaction type="Required"
*
- * @ejb:data-object setdata="false"
+ * @ejb:data-object setdata="true"
* extends="java.lang.Object"
*
* @ejb:finder signature="java.util.Collection findAll()"
*
- * @ejb:finder signature="java.util.Collection findLargeAccounts( int
pMinimumBalance )"
+ * @ejb:finder signature="java.util.Collection findByCustomer( String pCustomerId )"
*
- * @jboss:finder-query name="findLargeAccounts"
- * query="Balance < {0}"
- * order="Balance"
+ * @jboss:finder-query name="findByCustomer"
+ * query="Customer_Id = {0}"
+ * order="Type"
+ *
+ * @ejb:finder signature="org.jboss.test.banknew.interfaces.Account
findByCustomerAndType( String pCustomerId, int pType )"
+ *
+ * @jboss:finder-query name="findByCustomerAndType"
+ * query="Customer_Id = {0} AND Type = {1}"
*
* @jboss:table-name table-name="Account"
*
@@ -53,9 +58,6 @@
{
// Constants -
- public static final String COMP_NAME = "java:comp/env/ejb/bank/Account";
- public static final String JNDI_NAME = "ejb/bank/Account";
-
// Attributes
// Static
@@ -72,109 +74,79 @@
**/
abstract public String getId();
- abstract public void setId(String id);
+ abstract public void setId( String pId );
/**
* @ejb:persistent-field
-* @ejb:interface-method view-type="remote"
*
-* @jboss:column-name name="Balance"
+* @jboss:column-name name="Customer_Id"
**/
- abstract public float getBalance();
+ abstract public String getCustomerId();
- /**
-* @ejb:interface-method view-type="remote"
-**/
- abstract public void setBalance(float balance);
+ abstract public void setCustomerId( String pCustomerId );
/**
* @ejb:persistent-field
-* @ejb:interface-method view-type="remote"
*
-* @jboss:column-name name="Customer_Id"
+* @jboss:column-name name="Type"
**/
- public abstract String getOwnerId();
+ abstract public int getType();
- public abstract void setOwnerId( String pCustomerId );
+ abstract public void setType( int pType );
/**
+* @ejb:persistent-field
* @ejb:interface-method view-type="remote"
+*
+* @jboss:column-name name="Balance"
**/
- public void deposit(float amount)
- {
- setBalance(getBalance()+amount);
- }
+ abstract public float getBalance();
- /**
-* @ejb:interface-method view-type="remote"
-**/
- public void withdraw(float amount)
- {
- setBalance(getBalance()-amount);
- }
+ abstract public void setBalance( float pAmount );
/**
* @ejb:interface-met
[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-bank.xml build-bench.xml build-cts.xml build-hello.xml build-idgen.xml build-perf.xml
User: schaefera Date: 02/04/16 22:07:23 Modified:src/build/subprojects Tag: Branch_2_4 build-bank.xml build-bench.xml build-cts.xml build-hello.xml build-idgen.xml build-perf.xml Log: Redesigned the banknew example therefore to a create separation between the Entity Bean (CMP) and the Session Beans (Business Logic). The test cases are redesigned but not finished yet. Revision ChangesPath No revision No revision 1.1.2.2 +13 -6 jbosstest/src/build/subprojects/Attic/build-bank.xml Index: build-bank.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-bank.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- build-bank.xml9 Jul 2001 01:06:01 - 1.1.2.1 +++ build-bank.xml17 Apr 2002 05:07:23 - 1.1.2.2 @@ -20,8 +20,7 @@ - - + - + + + + 1.1.2.1 +14 -10jbosstest/src/build/subprojects/Attic/build-bench.xml Index: build-bench.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-bench.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- build-bench.xml 5 May 2001 20:54:05 - 1.1 +++ build-bench.xml 17 Apr 2002 05:07:23 - 1.1.2.1 @@ -21,16 +21,22 @@ - - + - + + + + - @@ -39,12 +45,10 @@ - - 1.1.2.2 +13 -6 jbosstest/src/build/subprojects/Attic/build-cts.xml Index: build-cts.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-cts.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- build-cts.xml 9 Jul 2001 01:06:01 - 1.1.2.1 +++ build-cts.xml 17 Apr 2002 05:07:23 - 1.1.2.2 @@ -20,8 +20,7 @@ - - + - + + + + 1.1.2.2 +13 -6 jbosstest/src/build/subprojects/Attic/build-hello.xml Index: build-hello.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-hello.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- build-hello.xml 9 Jul 2001 01:06:01 - 1.1.2.1 +++ build-hello.xml 17 Apr 2002 05:07:23 - 1.1.2.2 @@ -20,8 +20,7 @@ - - + - + + + + 1.1.2.1 +13 -6 jbosstest/src/build/subprojects/Attic/build-idgen.xml Index: build-idgen.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-idgen.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- build-idgen.xml 5 May 2001 20:54:05 - 1.1 +++ build-idgen.xml 17 Apr 2002 05:07:23 - 1.1.2.1 @@ -20,8 +20,7 @@ - - + - + + + + 1.1.2.4 +37 -21jbosstest/src/build/subprojects/Attic/build-perf.xml Index: build-perf.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-perf.xml,v retrieving revision 1.1.2.3 retrieving revision 1.1.2.4 diff -u -r1.1.2.3 -r1.1.2.4 --- build-perf.xml30 Sep 2001 21:23:40 - 1.1.2.3 +++ build-perf.xml17 Apr 2002 05:07:23 - 1.1.2.4 @@ -23,40 +23,56 @@ - - - + + - - - - - + + + + + + + - - - - - - + + + +
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/banknew/interfaces Constants.java
User: schaefera Date: 02/04/16 22:07:24 Added: src/main/org/jboss/test/banknew/interfaces Tag: Branch_2_4 Constants.java Log: Redesigned the banknew example therefore to a create separation between the Entity Bean (CMP) and the Session Beans (Business Logic). The test cases are redesigned but not finished yet. Revision ChangesPath No revision No revision 1.1.2.1 +36 -0 jbosstest/src/main/org/jboss/test/banknew/interfaces/Attic/Constants.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How are ejb-link relative refs really supposed to work?
Its a path relative to the codebase of the referring and I interpret
the example to imply the first case you mention. I base this on
the behavior of the URL(URL, String) ctor behavior. Consider
an ear with two jars j1.jar, j2.jar:
e1.ear/
--- j1.jar
--- j2.jar
j1.jar contains class C1, j2.jar contains class C2. Look at the behavior
of this program that obtains the location of the C1 class and then
forms the location of the C2 class based on the C1 codebase and
the two relative possible relative paths to C2("./j2.jar" and "../j2.jar"):
import java.net.URL;
class tstRelativeURL
{
public static void main(String[] args) throws Exception
{
Class c1 = Class.forName("C1");
URL c1URL = c1.getProtectionDomain().getCodeSource().getLocation();
System.out.println("C1 location: "+c1URL);
URL c2URL = new URL(c1URL, "./j2.jar");
System.out.println("C2 location: "+c2URL);
URL c22URL = new URL(c1URL, "../j2.jar");
System.out.println("C22 location: "+c22URL);
}
}
Java 1126>java -cp ".;j1.jar" tstRelativeURL
C1 location: file:/D:/tmp/Java/j1.jar
C2 location: file:/D:/tmp/Java/j2.jar
C22 location: file:/D:/tmp/j2.jar
Only the "./j2.jar" path results in a correct codebase from which C2 can be
loaded.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "David Jencks" <[EMAIL PROTECTED]>
To: "jboss-dev" <[EMAIL PROTECTED]>
Sent: Tuesday, April 16, 2002 9:11 PM
Subject: [JBoss-dev] How are ejb-link relative refs really supposed to work?
> IMO the j2ee spec does not clearly define the meaning of relative ejb-link
> elements. It gives and example of
>
> ../products/product.jar#ProductEJB
>
> What does the .. mean?
>
> I think it refers to this situation:
>
> accounting/accounting.jar (the ejb-jar.xml snippet above comes from this)
> products/products.jar (contains ProductEJB)
>
> However it could also refer to this:
>
> accounting.jar (the ejb-jar.xml snippet above comes from this)
> products/products.jar (contains ProductEJB)
>
> where the .. refers to getting out of the current jar.
>
> Ed Roman's book seems to mindlessly quote the spec without any additional
> info whatsoever.
>
> Any other opinions? Experience with other app servers?
>
> thanks
> david jencks
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 2.4.5 problem
Hi Bill
I got an exception when I ran this test (client-side) (this thread
is running ten times at the same time):
---
class RegularTeller
implements Runnable
{
public void run() {
int k = 0;
Random lRandom = new Random();
Category lLog = Category.getInstance( getClass().getName() );
try {
// Get bank first
Collection lBanks = getBankSession().getBanks();
System.out.println( "RegularTeller.run(), banks: " + lBanks );
BankData lBank = (BankData) lBanks.iterator().next();
while( !mExit && mException == null ) {
CustomerData lCustomer = null;
if( lRandom.nextInt( 100 ) < 10 ) {
lCustomer = getCustomerSession().createCustomer(
lBank.getId(), "test", 100 );
System.out.println( "RegularTeller.run(), new " +
lCustomer );
} else {
List lCustomers = (List) getBankSession().getCustomers(
lBank.getId() );
System.out.println( "RegularTeller.run(), # of customers:
" + lCustomers.size() );
lCustomer = (CustomerData) lCustomers.get(
lRandom.nextInt( lCustomers.size() ) );
}
}
---
the exception on the server-side:
---
javax.transaction.TransactionRolledbackException: removing bean lock and it
has tx set!; nested exception is:
java.lang.IllegalStateException: removing bean lock and it has tx
set!
java.lang.IllegalStateException: removing bean lock and it has tx set!
at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPessimis
ticEJBLock.java:468)
at
org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:78)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.jav
a:142)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:347)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12
7)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:428)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:504)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr
oxy.java:335)
at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityProxy.java:13
3)
at $Proxy249.getData(Unknown Source)
at
org.jboss.test.banknew.ejbeans.CustomerSessionBean.getCustomers(CustomerSess
ionBean.java:116)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles
sSessionContainer.java:542)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe
ssionInstanceInterceptor.java:82)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:347)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12
7)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170)
at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.jav
a:286)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:504)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr
oxy.java:335)
at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(Stateless
SessionProxy.java:123)
at $Proxy236.getCustomers(Unknown Source)
at
org.jboss.test.banknew.ejbeans.BankSessionBean.getCustomers(BankSessionBean.
java:114)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles
sSessionContainer.java:542)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe
ssionInstanceInterceptor.java:82)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:347)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12
7)
at
org.jboss.ejb.plugins.LogIntercepto
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 558 Successful tests: 530 Errors:22 Failures: 6 [time of test: 17 April 2002 5:24 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How are ejb-link relative refs really supposed to work?
IMO the j2ee spec does not clearly define the meaning of relative ejb-link elements. It gives and example of ../products/product.jar#ProductEJB What does the .. mean? I think it refers to this situation: accounting/accounting.jar (the ejb-jar.xml snippet above comes from this) products/products.jar (contains ProductEJB) However it could also refer to this: accounting.jar (the ejb-jar.xml snippet above comes from this) products/products.jar (contains ProductEJB) where the .. refers to getting out of the current jar. Ed Roman's book seems to mindlessly quote the spec without any additional info whatsoever. Any other opinions? Experience with other app servers? thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] where is findInRange for perf test?
There never has been a definition for findInRange and jaws 1.1 returns an empty enumeration for this nonexistent finder so the tests in 2.4 don't appear to fail. It needs to be defined. - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: "Jboss-Dev" <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 7:18 PM Subject: [JBoss-dev] where is findInRange for perf test? > I can't find where it is implemented and I don't see it as a default finder > in CMP 1.x or 2.x. > > org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange > org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. > > Thanks, > > Bill > > > ___ > 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] Stateful Session Beans are not EJB2.0 yet
Damn. I'm usually more careful than that. It must have been late. Anyway, I'm working up a test case which I'll attach to the bug report. On Wednesday, April 17, 2002, at 11:32 AM, Scott M Stark wrote: > The silence was most likely due to a poor bug report . There is > no selection of which version this applied to and no example > demonstrating the problem. Start with a testcase that uses a > custom container configuration to set a short passivation timeout. > > - Original Message - > From: "Stephen Coy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 16, 2002 5:23 PM > Subject: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet > > >> Hi, >> >> I raised a bug (#541855) about this a while ago, which has met a >> distressing amount of silence. >> >> In short, stateful session beans fail to passivate if they have >> EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, >> they fail to comply with 7.4.1 of the EJB 2.0 spec. >> >> I would tackle fixing this myself, but I don't yet know my way around >> inside the guts of JBoss well enough yet. Maybe one of the gurus can >> spend ten or fifteen minutes describing how to go about it - and then >> I'll be happy to write and test the implementation. >> >> Stephen Coy >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS with JBossMQ over high latency links
Before we go reinventing the wheel here, you might want to try the RMI IL. It's a littler slower on the serialization, but I think RMI will do some connection pooling for you. Regards, Hiram >From: Anatoly Akkerman <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] JMS with JBossMQ over high latency links >Date: Tue, 16 Apr 2002 16:15:55 -0500 > >Hi, guys > >I posted this on JMS/JBossMQ forum but it seems that posting to jboss-dev >will make this issue more visible. > >We are trying to run an MDB that listens to a Topic on a remote JMS >provider which resides across a high latency link. The behavior we >encountered was that with relatively high load (about 10 or so >messages/sec) the delay for all messages to reach the MDB gets to be very, >very large. (We are using the 'fastest' of the IL -- OIL) > >I dug into the Source and realized that, perhaps, this is due to the fact >that all methods that ServerIL and ClientIL interfaces expose end up being >synchronized in the OIL implementation. Judging from the source, this is >because in OIL you have to stuff everything down a single socket and since >multiple threads have access to a JMS Connection and it has to be thread >safe, synchronizing is a reasonable solution. On high latency links this is >a killer, though. I am wondering how much work would it involve to write an >extended OIL which can use a socket pool or something of that sort to >multiplex communications better. > >What do you say? > >Anatoly Akkerman. > >* * * > >View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=13074 > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] where is findInRange for perf test?
The question is, how do you get a 2.4 testsuite? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Tuesday, April 16, 2002 11:03 PM > To: Bill Burke > Cc: Jboss-Dev > Subject: Re: [JBoss-dev] where is findInRange for perf test? > > > I could have sworn it was specified in a query in a jaws.xml but I sure > can't find any trace of such a file. > > If you have a copy of the 2.4 testsuite you might look there. > > david jencks > > On 2002.04.16 22:18:51 -0400 Bill Burke wrote: > > I can't find where it is implemented and I don't see it as a default > > finder > > in CMP 1.x or 2.x. > > > > org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange > > org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. > > > > Thanks, > > > > Bill > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 534 Errors:22 Failures: 7 [time of test: 17 April 2002 3:51 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] where is findInRange for perf test?
I could have sworn it was specified in a query in a jaws.xml but I sure can't find any trace of such a file. If you have a copy of the 2.4 testsuite you might look there. david jencks On 2002.04.16 22:18:51 -0400 Bill Burke wrote: > I can't find where it is implemented and I don't see it as a default > finder > in CMP 1.x or 2.x. > > org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange > org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. > > Thanks, > > Bill > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: patriot1burke Date: 02/04/16 19:43:03 Modified:src/main/org/jboss/ejb Tag: Branch_3_0 Container.java Log: don't set lockmanager to null. Passivation thread may be trying to access it on an undeploy. Revision ChangesPath No revision No revision 1.85.2.1 +2 -2 jboss/src/main/org/jboss/ejb/Container.java Index: Container.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v retrieving revision 1.85 retrieving revision 1.85.2.1 diff -u -r1.85 -r1.85.2.1 --- Container.java12 Apr 2002 19:30:41 - 1.85 +++ Container.java17 Apr 2002 02:43:03 - 1.85.2.1 @@ -82,7 +82,7 @@ * @author mailto:[EMAIL PROTECTED]";>Scott Stark. * @author Bill Burke * @author mailto:[EMAIL PROTECTED]";>David Jencks -* @version $Revision: 1.85 $ +* @version $Revision: 1.85.2.1 $ ** Revisions: * * 2001/07/26 bill burke: @@ -591,7 +591,7 @@ this.webClassLoader = null; this.localClassLoader = null; this.ejbModule = null; - this.lockManager = null; + // this.lockManager = null; Setting this to null causes AbstractCache to fail on undeployment this.methodPermissionsCache.clear(); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: patriot1burke Date: 02/04/16 19:44:13 Modified:src/main/org/jboss/ejb Container.java Log: don't set lockmanager to null. Passivation thread may be trying to access it on an undeploy. Revision ChangesPath 1.86 +2 -2 jboss/src/main/org/jboss/ejb/Container.java Index: Container.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v retrieving revision 1.85 retrieving revision 1.86 diff -u -r1.85 -r1.86 --- Container.java12 Apr 2002 19:30:41 - 1.85 +++ Container.java17 Apr 2002 02:44:13 - 1.86 @@ -82,7 +82,7 @@ * @author mailto:[EMAIL PROTECTED]";>Scott Stark. * @author Bill Burke * @author mailto:[EMAIL PROTECTED]";>David Jencks -* @version $Revision: 1.85 $ +* @version $Revision: 1.86 $ ** Revisions: * * 2001/07/26 bill burke: @@ -591,7 +591,7 @@ this.webClassLoader = null; this.localClassLoader = null; this.ejbModule = null; - this.lockManager = null; + // this.lockManager = null; Setting this to null causes AbstractCache to fail on undeployment this.methodPermissionsCache.clear(); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] where is findInRange for perf test?
I can't find where it is implemented and I don't see it as a default finder in CMP 1.x or 2.x. org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: naming test failures
No, but I fixed that already. I'm looking into the link support. david On 2002.04.16 21:41:52 -0400 Bill Burke wrote: > I don't know the ear spec very well. > > If you put: > - > naminga.jar > > > Should it be able to find naminga.jar in a subdirectory in the jar? > > > -Original Message- > > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 16, 2002 9:36 PM > > To: Bill Burke > > Subject: Re: naming test failures > > > > > > > > Then that is something different. > > > > - Original Message - > > From: "Bill Burke" <[EMAIL PROTECTED]> > > To: "Scott M Stark" <[EMAIL PROTECTED]> > > Sent: Tuesday, April 16, 2002 6:18 PM > > Subject: RE: naming test failures > > > > > > > Are you sure? THe ear doesn't even deploy. > > > > > > > -Original Message- > > > > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, April 16, 2002 9:20 PM > > > > To: Bill Burke > > > > Subject: Re: naming test failures > > > > > > > > > > > > > > > > No, but these are failing because we don't support cross > > ejb-jar links. > > > > > > > > - Original Message - > > > > From: "Bill Burke" <[EMAIL PROTECTED]> > > > > To: "Scott M Stark" <[EMAIL PROTECTED]> > > > > Sent: Tuesday, April 16, 2002 6:03 PM > > > > Subject: naming test failures > > > > > > > > > > > > > I'm looking into them, so let me know if you're doing the same. > > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-544963 ] "file:" protocol incompatible with Sun's
Patches item #544963, was opened at 2002-04-16 19:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=544963&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Sanderson (lsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: "file:" protocol incompatible with Sun's
Initial Comment:
JBoss has overriden the file: protocol to provide
better lastModified information. The following code
works with the default file handler, but not with
JBoss:
[code]
URL parent = new URL("file:C:\some\directory\");
URL file = new URL(parent, "myFile.txt");
[/code]
The problem is that the back-slashes are not converted
to forward-slashes, and the URL constructor does not
create a propper sub-URL. (If you println the URL
above, you get: "file:myFile.txt", instead of the
correct: "file:C:/some/directory/myFile.txt")
This patch is required to use the JCE libraries with
jdk1.4 and JBoss 3.0. The JCE classes have a hard-
coded reference to the URL: "file:${java.home}
\jre\lib\security", and it attempts to access the
sub-file: US_export_policy.jar.
-Larry
Index:
common/src/main/org/jboss/net/protocol/file/Handler.jav
a
===
RCS file: /cvsroot/jboss/jboss-
common/src/main/org/jboss/net/protocol/file/Handler.jav
a,v
retrieving revision 1.1
diff -u -r1.1 Handler.java
---
common/src/main/org/jboss/net/protocol/file/Handler.jav
a 4 Apr 2002 22:20:22 - 1.1
+++
common/src/main/org/jboss/net/protocol/file/Handler.jav
a 17 Apr 2002 02:02:07 -
@@ -14,6 +14,7 @@
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;
+import java.io.File;
/**
* A protocol handler for the 'file' protocol.
@@ -28,5 +29,10 @@
throws IOException
{
return new FileURLConnection(url);
+ }
+
+ protected void parseURL(URL url, String s, int i,
int j)
+ {
+ super.parseURL(url, s.replace
(File.separatorChar, '/'), i, j);
}
}
Index:
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java
===
RCS file: /cvsroot/jboss/jboss-
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java,v
retrieving revision 1.5
diff -u -r1.5 FileURLConnection.java
---
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java 6 Apr 2002 05:19:35 - 1.5
+++
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java 17 Apr 2002 02:00:18 -
@@ -41,7 +41,7 @@
{
super(url);
- file = new File(url.getFile());
+ file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
doOutput = false;
}
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=544963&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/ear/META-INF application.xml
User: d_jencks Date: 02/04/16 18:54:34 Modified:src/resources/naming/ear/META-INF Tag: Branch_3_0 application.xml Log: include path to naminga.jar so it can be found after new EarDeployer strictness Revision ChangesPath No revision No revision 1.1.2.1 +1 -1 jbosstest/src/resources/naming/ear/META-INF/application.xml Index: application.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/ear/META-INF/application.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- application.xml 17 Mar 2002 12:56:29 - 1.1 +++ application.xml 17 Apr 2002 01:54:34 - 1.1.2.1 @@ -4,7 +4,7 @@ naming ear test - naminga.jar + subdir/naminga.jar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Are we logging the exception enough!!!
Sounds very interesting and tempting but how do you propose someone do this without RW. This will require modifying a multitude of files. If someone does not have RW, the files will quickly become out of sync. The merge would be a nightmare. I would think the process would be in 2 steps. 1. Remove the redundant log statements. (low impact) 2. Then address the exceptions * * * View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=13067 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config db2-service.xml
User: d_jencks Date: 02/04/16 18:27:26 Added: src/etc/example-config Tag: Branch_3_0 db2-service.xml Log: contributed db2 local tx example, lost track of who submitted it. Please identify yourself so I can credit you. Revision ChangesPath No revision No revision 1.1.2.1 +93 -0 jbosscx/src/etc/example-config/Attic/db2-service.xml ___ 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/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] [ jboss-Bugs-539096 ] Lack of Reasonable Error on Deployment
Bugs item #539096, was opened at 2002-04-03 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=539096&group_id=22866 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Jay Walters (jwalters) Summary: Lack of Reasonable Error on Deployment Initial Comment: I am using jboss3.0+tomcat the build from 02.22.2002. I just attempted to deploy an entity bean, where in the deployment descriptor, i specified the incorrect classname to one that did not exist. The messages on the console were just: [Bean Deployer] Deploying: file:/bla... In cases where something is as blatently wrong as a class name that does not exist in the jar file, normal users will expect somesort of error message. Maybe a ClassNotFoundException. -- >Comment By: Jay Walters (jwalters) Date: 2002-04-16 21:49 Message: Logged In: YES user_id=183794 The EJB 2.0 verifier is in the 3.0 branch and it identifies this type of problem. -- Comment By: Peter Luttrell (objec) Date: 2002-04-05 00:27 Message: Logged In: YES user_id=472835 thanks. -- Comment By: Jay Walters (jwalters) Date: 2002-04-05 00:19 Message: Logged In: YES user_id=183794 The EJB 2.0 verifier currently doesn't work - it is stubbed out. I am working on this and will have a working verifier checked into the head by the end of the weekend. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=539096&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
> > > >-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB > > > -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBS > ngleton > > > > Any reason why the service can not set these props? Oops... Not really... This is much better indeed. I'll change the service to do it. > >If the JVM is an IBM one I also add > $JBOSS_HOME/lib/jacorb.jar to > >the classpath. > > > > Why the special case for IBM? > You're asking too many embarassing questions today, Jason... :-) I guess the answer is: because this way it works... In other words: I don't really know. Without jacorb.jar in the classpath, IBM VMs give me the following exception: 2002-04-16 21:55:19,323 DEBUG [org.jboss.deployment.MainDeployer] start step for deployment file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/server/d efault/deploy/iiop-service.xml 2002-04-16 21:55:19,324 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, start step: url file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/serv er/default/deploy/iiop-service.xml 2002-04-16 21:55:19,324 INFO [org.jboss.iiop.CorbaORBService] Starting 2002-04-16 21:55:20,057 INFO [STDOUT] JacORB V 1.4 beta 4, www.jacorb.org 2002-04-16 21:55:20,058 INFO [STDOUT] (C) Gerald Brose, FU Berlin, March 2002 2002-04-16 21:55:21,527 ERROR [org.jboss.deployment.MainDeployer] could not star t deployment :file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/server /default/deploy/iiop-service.xml org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation org.jacorb.orb.ORBSingleton minor code: 0 completed: No at org.omg.CORBA.ORB.create_impl(ORB.java:330) at org.omg.CORBA.ORB.init(ORB.java:308) at org.omg.CONV_FRAME.CodeSetComponentInfoHelper.(CodeSetCompone ntInfoHelper.java:12) at org.jacorb.orb.standardInterceptors.CodeSetInfoInterceptor.(Cod eSetInfoInterceptor.java:41) at org.jacorb.orb.standardInterceptors.IORInterceptorInitializer.post_in it(IORInterceptorInitializer.java:43) at org.jacorb.orb.ORB.interceptorInit(ORB.java:1347) at org.jacorb.orb.ORB.set_parameters(ORB.java:1262) at org.omg.CORBA.ORB.init(ORB.java:389) at org.jboss.iiop.CorbaORBService.startService(CorbaORBService.java:124) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 62) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:867) at $Proxy0.start(Unknown Source) ... (I'm on the forums. Pasted the stack trace to this little text input field in a web browser. Probably the stack trace will be badly reformatted. Anyway...) Sun VMs do not give me this exception. And I do not get the exception with an IBM VM if I put jacorb.jar in the classpath. There is some difference in classloader behavior I don't really understand. Cheers, Francisco * * * View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=12918 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: naming test failures
I don't know the ear spec very well. If you put: - naminga.jar Should it be able to find naminga.jar in a subdirectory in the jar? > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 16, 2002 9:36 PM > To: Bill Burke > Subject: Re: naming test failures > > > > Then that is something different. > > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Sent: Tuesday, April 16, 2002 6:18 PM > Subject: RE: naming test failures > > > > Are you sure? THe ear doesn't even deploy. > > > > > -Original Message- > > > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 16, 2002 9:20 PM > > > To: Bill Burke > > > Subject: Re: naming test failures > > > > > > > > > > > > No, but these are failing because we don't support cross > ejb-jar links. > > > > > > - Original Message - > > > From: "Bill Burke" <[EMAIL PROTECTED]> > > > To: "Scott M Stark" <[EMAIL PROTECTED]> > > > Sent: Tuesday, April 16, 2002 6:03 PM > > > Subject: naming test failures > > > > > > > > > > I'm looking into them, so let me know if you're doing the same. > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-543963 ] CMP Verifier doesn't check superclasses
Bugs item #543963, was opened at 2002-04-15 01:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=543963&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Jay Walters (jwalters)
Summary: CMP Verifier doesn't check superclasses
Initial Comment:
If I have a base class bean:
public interface Applicant
extends javax.ejb.EJBObject
{
// ... various setters and getters
}
and a superclass:
public interface PrivateApplicant
extends Applicant
{
// ... various other setters and getters
}
then EJBVerifier20 does not check the superclass
for the presence of declared methods, resulting in:
Section: 10.6.2
Warning: The entity bean class must define a get
accessor for each CMP field.
etc.
Presumably, it should.
--
>Comment By: Jay Walters (jwalters)
Date: 2002-04-16 21:48
Message:
Logged In: YES
user_id=183794
Fixed in the 3.0 branch. I'll put it into the CVS head
later this week.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=543963&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
The silence was most likely due to a poor bug report . There is no selection of which version this applied to and no example demonstrating the problem. Start with a testcase that uses a custom container configuration to set a short passivation timeout. - Original Message - From: "Stephen Coy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 5:23 PM Subject: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet > Hi, > > I raised a bug (#541855) about this a while ago, which has met a > distressing amount of silence. > > In short, stateful session beans fail to passivate if they have > EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, > they fail to comply with 7.4.1 of the EJB 2.0 spec. > > I would tackle fixing this myself, but I don't yet know my way around > inside the guts of JBoss well enough yet. Maybe one of the gurus can > spend ten or fifteen minutes describing how to go about it - and then > I'll be happy to write and test the implementation. > > Stephen Coy > > > ___ > 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] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 538 Errors:21 Failures: 4 [time of test: 17 April 2002 2:33 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-541855 ] Passivation of stateful sess beans fails
Bugs item #541855, was opened at 2002-04-10 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=541855&group_id=22866 >Category: JBossServer >Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Nobody/Anonymous (nobody) Summary: Passivation of stateful sess beans fails Initial Comment: Section 7.4.1 of the EJB2.0 spec says that EJBLocalHome and EJBLocalObject (amongst others) should be persisted during passivation. The code in org.jboss.ejb.plugins.SessionObjectOutputStream clearly doesn't do this yet. Someone needs to check and ifx this code for EJB2.0 conformance. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=541855&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config db2-service.xml
User: d_jencks Date: 02/04/16 18:29:43 Added: src/etc/example-config db2-service.xml Log: merged from branch 3.0 Revision ChangesPath 1.2 +93 -0 jbosscx/src/etc/example-config/db2-service.xml ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Compile problem with iiop
I just fixed this on my windows box by installing the latest version of the JDK 1.3.1_03. -dain Vesco Claudio wrote: > Hi! > > If I remember well, this is a problem with rmic but I have encontered this > problem in WindowsNT sun jdk 1.3. > > You have said that you are in linux and linux are the Francisco's main > development platform. > > In WindowsNT sun jdk 1.4 this problem go out. > > In order to obviate to the problem you can try to copy jboss-j2ee.jar in > $JAVA_HOME/jre/lib/ext :-( > > Claudio > > >>-Original Message- >>From: David Jencks [SMTP:[EMAIL PROTECTED]] >>Sent: Tuesday, April 16, 2002 6:43 AM >>To: jboss-dev >>Subject: [JBoss-dev] Compile problem with iiop >> >>Anyone else getting this from the iiop module? >> >>I have linux 2.4.16, jdk 1.3.1_03 from sun. >> >>Any advice? >> >>compile-rmi: >>Verify has been turned on. >>RMI Compiling 1 class to >>/usr/java/jboss/co12/jboss-all/iiop/output/classes >>IIOP has been turned on. >>java.lang.UnsatisfiedLinkError: hasStaticInitializer >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.hasStaticInitializer(Native >>Method) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass._computeSerialVersionUID(Ob >>jectStreamClass.java:943) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.(ObjectStreamClass.ja >>va:459) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStream >>Class.java:139) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.ja >>va:96) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStream >>Class.java:133) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.ja >>va:96) >> at >>com.sun.corba.ee.internal.io.ObjectStreamClass.getSerialVersionUID(ObjectS >>treamClass.java:159) >> at >>com.sun.corba.ee.internal.util.RepositoryId.(RepositoryId.java:150 >>) >> at sun.rmi.rmic.iiop.IDLNames.convertToISOLatin1(IDLNames.java:139) >> at >>sun.rmi.rmic.iiop.IDLNames.getClassOrInterfaceName(IDLNames.java:233) >> at sun.rmi.rmic.iiop.CompoundType.(CompoundType.java:644) >> at sun.rmi.rmic.iiop.InterfaceType.(InterfaceType.java:104) >> at sun.rmi.rmic.iiop.RemoteType.(RemoteType.java:115) >> at sun.rmi.rmic.iiop.RemoteType.forRemote(RemoteType.java:79) >> at >>sun.rmi.rmic.iiop.StubGenerator.getTopType(StubGenerator.java:119) >> at sun.rmi.rmic.iiop.Generator.generate(Generator.java:262) >> at sun.rmi.rmic.Main.doCompile(Main.java:526) >> at sun.rmi.rmic.Main.compile(Main.java:133) >> at java.lang.reflect.Method.invoke(Native Method) >> at >>org.apache.tools.ant.taskdefs.rmic.SunRmic.execute(SunRmic.java:89) >> at org.apache.tools.ant.taskdefs.Rmic.execute(Rmic.java:397) >> at org.apache.tools.ant.Task.perform(Task.java:217) >> at org.apache.tools.ant.Target.execute(Target.java:164) >> at org.apache.tools.ant.Target.performTasks(Target.java:182) >> at org.apache.tools.ant.Project.executeTarget(Project.java:601) >> at org.apache.tools.ant.Project.executeTargets(Project.java:560) >> at org.apache.tools.ant.Main.runBuild(Main.java:454) >> at org.apache.tools.ant.Main.start(Main.java:153) >> at org.apache.tools.ant.Main.main(Main.java:176) >>error: An error has occurred in the compiler; please file a bug report >>(http://java.sun.com/cgi-bin/bugreport.cgi). >>1 error >> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jca/test CachedConnectionBankStressTestCase.java CachedConnectionSessionUnitTestCase.java
User: d_jencks Date: 02/04/16 18:07:54 Removed: src/main/org/jboss/test/jca/test Tag: Branch_3_0 CachedConnectionBankStressTestCase.java CachedConnectionSessionUnitTestCase.java Log: These tests require new jca-jdbc wrappers to pass, and these won't be in jboss 3.0, so I am removing the tests from this branch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
I would *guess* it would as simple as adding another bean test, which deployed a 2.0 bean with local fluff, then perhaps jmx to the server and ask the container to passivate. I am not sure if there is a such a mechanism exposed via jmx right now todo this, but it might be useful. It might also be possible to test this in isolation, but that is more work and not really an option with the current tessuite setup... --jason Quoting Stephen Coy <[EMAIL PROTECTED]>: > Nope. > > How would you automate testing it? I know it doesn't work because I've > observed it in the console log. > > On Wednesday, April 17, 2002, at 10:58 AM, Jason Dillon wrote: > > > Does the testsuite cover these? > > > > --jason > > > > > > Quoting Hunter Hillegas <[EMAIL PROTECTED]>: > > > >> I think some part of them is not marked as serializable... > >> > >>> From: Jason Dillon <[EMAIL PROTECTED]> > >>> Date: Tue, 16 Apr 2002 17:41:19 -0700 > >>> To: Stephen Coy <[EMAIL PROTECTED]> > >>> Cc: [EMAIL PROTECTED] > >>> Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet > >>> > >>> Any clue why they fail? > >>> > >>> --jason > >>> > >>> > >>> Quoting Stephen Coy <[EMAIL PROTECTED]>: > >>> > Hi, > > I raised a bug (#541855) about this a while ago, which has met a > distressing amount of silence. > > In short, stateful session beans fail to passivate if they have > EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, > they fail to comply with 7.4.1 of the EJB 2.0 spec. > > I would tackle fixing this myself, but I don't yet know my way around > inside the guts of JBoss well enough yet. Maybe one of the gurus can > spend ten or fifteen minutes describing how to go about it - and then > I'll be happy to write and test the implementation. > > Stephen Coy > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > >>> > >>> > >>> > >>> > >>> - > >>> This mail sent through IMP: http://horde.org/imp/ > >>> > >>> ___ > >>> Jboss-development mailing list > >>> [EMAIL PROTECTED] > >>> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > > > > > - > > This mail sent through IMP: http://horde.org/imp/ > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
User: starksm
Date: 02/04/16 17:55:36
Modified:src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
Log:
The loadClass(String) method must query the current TCL if the
if the repository does not contain the requested class and the
TCL is not a UnifiedClassLoader as the TCL will not be queried
by the loadClass(String, boolean, ClassLoader) method in this
instance. This was the reason for the
org.jboss.test.jbossmx.compliance.timer.BasicTestCase failures.
Revision ChangesPath
1.3 +19 -8 jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java
Index: UnifiedLoaderRepository.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UnifiedLoaderRepository.java 15 Apr 2002 02:48:51 - 1.2
+++ UnifiedLoaderRepository.java 17 Apr 2002 00:55:36 - 1.3
@@ -37,7 +37,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
* just a hint... xdoclet not really used
* @jmx.name="JMImplementation:service=UnifiedLoaderRepository,name=Default"
*
@@ -113,14 +113,11 @@
/**
* Add a class to this repository. Allows a class to be added in
* byte code form stored inside this repository.
-/**
-* Load a class in this repository.
*
* @param name The name of the class
* @param resolve If true, the class will be resolved
* @param scl The asking class loader
-* @return The loaded class.
-* resource could not be found.
+* @return The loaded class
* @throws ClassNotFoundException If the class could not be found.
*/
public Class loadClass(String name, boolean resolve, ClassLoader scl)
@@ -165,7 +162,7 @@
{
}
}
-
+
if (foundClass == null)
{
Iterator allLoaders = classLoaders2.iterator();
@@ -384,9 +381,23 @@
// if someone comes to us directly through LoaderRepository interface
// notice that UCL loaders will skip this and invoke
// loadClass(name, resolve, cl) directly
- return loadClass(className, false,
Thread.currentThread().getContextClassLoader());
+ ClassLoader scl = Thread.currentThread().getContextClassLoader();
+ Class clazz = null;
+ try
+ {
+ clazz = loadClass(className, false, scl);
+ }
+ catch(ClassNotFoundException e)
+ {
+ /* If the TCL is not a UnifiedClassLoader then the scl was not asked
+ if it could load the class. Do so here.
+ */
+ if( (scl instanceof UnifiedClassLoader) == false )
+clazz = scl.loadClass(className);
+ }
+ return clazz;
}
-
+
public Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException
{
throw new Error("NYI");
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
I think some part of them is not marked as serializable... > From: Jason Dillon <[EMAIL PROTECTED]> > Date: Tue, 16 Apr 2002 17:41:19 -0700 > To: Stephen Coy <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet > > Any clue why they fail? > > --jason > > > Quoting Stephen Coy <[EMAIL PROTECTED]>: > >> Hi, >> >> I raised a bug (#541855) about this a while ago, which has met a >> distressing amount of silence. >> >> In short, stateful session beans fail to passivate if they have >> EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, >> they fail to comply with 7.4.1 of the EJB 2.0 spec. >> >> I would tackle fixing this myself, but I don't yet know my way around >> inside the guts of JBoss well enough yet. Maybe one of the gurus can >> spend ten or fifteen minutes describing how to go about it - and then >> I'll be happy to write and test the implementation. >> >> Stephen Coy >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > 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] Stateful Session Beans are not EJB2.0 yet
Does the testsuite cover these? --jason Quoting Hunter Hillegas <[EMAIL PROTECTED]>: > I think some part of them is not marked as serializable... > > > From: Jason Dillon <[EMAIL PROTECTED]> > > Date: Tue, 16 Apr 2002 17:41:19 -0700 > > To: Stephen Coy <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet > > > > Any clue why they fail? > > > > --jason > > > > > > Quoting Stephen Coy <[EMAIL PROTECTED]>: > > > >> Hi, > >> > >> I raised a bug (#541855) about this a while ago, which has met a > >> distressing amount of silence. > >> > >> In short, stateful session beans fail to passivate if they have > >> EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, > >> they fail to comply with 7.4.1 of the EJB 2.0 spec. > >> > >> I would tackle fixing this myself, but I don't yet know my way around > >> inside the guts of JBoss well enough yet. Maybe one of the gurus can > >> spend ten or fifteen minutes describing how to go about it - and then > >> I'll be happy to write and test the implementation. > >> > >> Stephen Coy > >> > >> > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > > > > > - > > This mail sent through IMP: http://horde.org/imp/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Nope. How would you automate testing it? I know it doesn't work because I've observed it in the console log. On Wednesday, April 17, 2002, at 10:58 AM, Jason Dillon wrote: > Does the testsuite cover these? > > --jason > > > Quoting Hunter Hillegas <[EMAIL PROTECTED]>: > >> I think some part of them is not marked as serializable... >> >>> From: Jason Dillon <[EMAIL PROTECTED]> >>> Date: Tue, 16 Apr 2002 17:41:19 -0700 >>> To: Stephen Coy <[EMAIL PROTECTED]> >>> Cc: [EMAIL PROTECTED] >>> Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet >>> >>> Any clue why they fail? >>> >>> --jason >>> >>> >>> Quoting Stephen Coy <[EMAIL PROTECTED]>: >>> Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >>> >>> >>> - >>> This mail sent through IMP: http://horde.org/imp/ >>> >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > > - > This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
User: starksm
Date: 02/04/16 17:53:46
Modified:src/main/org/jboss/mx/loading Tag: Branch_3_0
UnifiedLoaderRepository.java
Log:
The loadClass(String) method must query the current TCL if the
if the repository does not contain the requested class and the
TCL is not a UnifiedClassLoader as the TCL will not be queried
by the loadClass(String, boolean, ClassLoader) method in this
instance. This was the reason for the
org.jboss.test.jbossmx.compliance.timer.BasicTestCase failures.
Revision ChangesPath
No revision
No revision
1.2.2.1 +19 -8 jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java
Index: UnifiedLoaderRepository.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- UnifiedLoaderRepository.java 15 Apr 2002 02:48:51 - 1.2
+++ UnifiedLoaderRepository.java 17 Apr 2002 00:53:46 - 1.2.2.1
@@ -37,7 +37,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.2.2.1 $
* just a hint... xdoclet not really used
* @jmx.name="JMImplementation:service=UnifiedLoaderRepository,name=Default"
*
@@ -113,14 +113,11 @@
/**
* Add a class to this repository. Allows a class to be added in
* byte code form stored inside this repository.
-/**
-* Load a class in this repository.
*
* @param name The name of the class
* @param resolve If true, the class will be resolved
* @param scl The asking class loader
-* @return The loaded class.
-* resource could not be found.
+* @return The loaded class
* @throws ClassNotFoundException If the class could not be found.
*/
public Class loadClass(String name, boolean resolve, ClassLoader scl)
@@ -165,7 +162,7 @@
{
}
}
-
+
if (foundClass == null)
{
Iterator allLoaders = classLoaders2.iterator();
@@ -384,9 +381,23 @@
// if someone comes to us directly through LoaderRepository interface
// notice that UCL loaders will skip this and invoke
// loadClass(name, resolve, cl) directly
- return loadClass(className, false,
Thread.currentThread().getContextClassLoader());
+ ClassLoader scl = Thread.currentThread().getContextClassLoader();
+ Class clazz = null;
+ try
+ {
+ clazz = loadClass(className, false, scl);
+ }
+ catch(ClassNotFoundException e)
+ {
+ /* If the TCL is not a UnifiedClassLoader then the scl was not asked
+ if it could load the class. Do so here.
+ */
+ if( (scl instanceof UnifiedClassLoader) == false )
+clazz = scl.loadClass(className);
+ }
+ return clazz;
}
-
+
public Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException
{
throw new Error("NYI");
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Because there is not yet any code in place to handle the passivation of these objects. If you look in org.jboss.ejb.plugins.SessionObjectOutputStream you can see that it's only the original EJB1.1 stuff. EJBLocalObject and EJBLocalHome are not serializable, and so must be specially handled together with their remote brethren in SessionObjectOutputStream.replaceObject, not to mention the corresponding activation code in SessionObjectInputStream. On Wednesday, April 17, 2002, at 10:41 AM, Jason Dillon wrote: > Any clue why they fail? > > --jason > > > Quoting Stephen Coy <[EMAIL PROTECTED]>: > >> Hi, >> >> I raised a bug (#541855) about this a while ago, which has met a >> distressing amount of silence. >> >> In short, stateful session beans fail to passivate if they have >> EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, >> they fail to comply with 7.4.1 of the EJB 2.0 spec. >> >> I would tackle fixing this myself, but I don't yet know my way around >> inside the guts of JBoss well enough yet. Maybe one of the gurus can >> spend ten or fifteen minutes describing how to go about it - and then >> I'll be happy to write and test the implementation. >> >> Stephen Coy >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > > - > This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 527 Errors:21 Failures: 15 [time of test: 17 April 2002 1:46 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Any clue why they fail? --jason Quoting Stephen Coy <[EMAIL PROTECTED]>: > Hi, > > I raised a bug (#541855) about this a while ago, which has met a > distressing amount of silence. > > In short, stateful session beans fail to passivate if they have > EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, > they fail to comply with 7.4.1 of the EJB 2.0 spec. > > I would tackle fixing this myself, but I don't yet know my way around > inside the guts of JBoss well enough yet. Maybe one of the gurus can > spend ten or fifteen minutes describing how to go about it - and then > I'll be happy to write and test the implementation. > > Stephen Coy > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/util TestDBDriver.java TestConnection.java
User: d_jencks Date: 02/04/16 17:37:26 Removed: src/main/org/jboss/test/util Tag: Branch_3_0 TestDBDriver.java TestConnection.java Log: remove unused classes that have problems in jdk 1.4 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Lets ditch the testsuite bin scripts
I like them... they make me feel warm and fuzzy and that god loves me. If you remove them does that mean that god won't love me anymore? * * * Who am I kidding... there is no god, so nuke em. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > Does anyone have a problem with deleting all the testsuite/src/bin scripts? > IMO they are 200% obsolete given the current test framework. > > david jencks > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-544778 ] generation of uni-directional CMR b0rked
Bugs item #544778, was opened at 2002-04-16 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544778&group_id=22866 Category: JBossCMP Group: CVS HEAD >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christian Riege (lqd) Assigned to: Dain Sundstrom (dsundstrom) Summary: generation of uni-directional CMR b0rked Initial Comment: it seems that when trying to use a UNIdirectional CMR relationship JBossCMP insists on creating a foreign key field on BOTH sides of the relationship. this should not be; JBossCMP should ignore the side of the relationship where no element is defined. snippet from ejb-jar.xml: A-Uni-B a-uni-b One A fk_field b-maps-a One B the tables created look like this: table_a a_id a_fk_field table_b b_id b_a_fk_field the field 'b_a_fk_field' should *not* be generated in my opinion as it is not declared in the deployment descriptor; i.e. it has no matching entry. (jbosscmp-jdbc.xml is empty except for element). tested against both jboss 3.0rc1 as well as CVS HEAD. -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-04-16 19:10 Message: Logged In: YES user_id=251431 As you said this is an opinion thing. I don't think it matters what the default is as long a it works and it can be overriden. If there is community support for this change I'll make it. I'm closing this, as it is not a bug. Start a discussion on the jboss-user list or in the db forum if you really want change. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544778&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Lets ditch the testsuite bin scripts
Does anyone have a problem with deleting all the testsuite/src/bin scripts? IMO they are 200% obsolete given the current test framework. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 561 Successful tests: 523 Errors:22 Failures: 16 [time of test: 17 April 2002 0:59 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Are we logging the exception enough!!!
Here is the strategy I follow in JBossCMP: Low-level non recoverable exceptions (SQLException, IOException...) are wrapped in an EJBException. (Not RemoteException or ServerException as is required by the spec). When catching an Exception, first check for EJBException, and just rethrow. (avoid EJBException in EJBException) Only log an exception if wrapping with an exception that does not support sub exception (CreateException and RemoveException). -dain Jason Dillon wrote: > Sounds like MainDeployer should be the one to log this exception. > > I have noticed that we generally misuse exceptions in many places... ie. > catching exceptions to log, then rethrow, or just to ignore. There are also > places where we wrap exceptions when we could really just add a checked > Exception to the method and let higher level logic handle the failure. > > This was the case with ServiceMBeanSupport.stopService() in previous > releases. I changed this to declare a checked Exception which simplifies > implementing services, as they don't need to handle the exceptions that occu > here, the support class does that for you. > > Anyways, my point is that I think we can clean up our exception/throwable > usage significantly. Doing so will simplify code which is current handling > some exceptions as well as make it easier to debug, as we won't have a billon > traces for a single exception. > > It is a big job though... to clean this up, which is why I think it has not > been attempted before. > > We might also want to provide a guide for new developers on how to deal with > exception coding, as it seems to be a common problem. > > --jason > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.0.0 RC1 is available
on 16-04-2 01.51, marc fleury at [EMAIL PROTECTED] wrote: > > |4 in all + the backup of thousands more - cool ... > | > |;-) > | > |Love > > Love indeed my friend, your english is greatly improved > > "Bouge de la" ahhh ... Du menar denna "bara i tanken" by ? ... Kan inte franska ... vill *inte* kunna franska ... finmaskigheten i deras språk ger klasstillhörigheten hos dom, därför har dom i allmänhet svårt för andra språk !!! då hela deras hela förståelse av "varandet" bygger på språkets 'tonart' ... älskar dock människorna och landet ! ... Förlåt ... för mycket brus ... ;-) DADA /peter/f > marcf > > |/peter_f > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-544913 ] Resultsets read in column order
Change Notes item #544913, was opened at 2002-04-16 18:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=544913&group_id=22866 Category: JBossCMP Group: v2.4.5 Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: Resultsets read in column order Initial Comment: Applied patch #520200 to fix bug #517062. This related to some JDBC drivers (notably the free Microsoft SQL Server driver by Merant) requiring that columns be read in the order they are specified in the query. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=544913&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-517062 ] JAWS ResultSet Column Order
Bugs item #517062, was opened at 2002-02-13 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517062&group_id=22866 Category: JBossServer Group: v2.4 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Prescott (fuseboy) Assigned to: Dan Christopherson (danch) Summary: JAWS ResultSet Column Order Initial Comment: The free and otherwise decent Microsoft JDBC Driver for SQL Server 2000 (they've licensed Merant's driver) has a limitation that requires that 'TEXT' fields be retrieved from ResultSets in the order that they're specified in the SELECT statement. JAWS composes the SELECT statement based on the order that CMP fields are returned from a Hashtable (effectively an undefined order), but moves primary key fields to be the first columns in the SELECT statement. (See http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jboss/src/main/org/jboss/ejb/plug ins/jaws/jdbc/JDBCLoadEntityCommand.java?annotate=1.18 lines 214-242). On retrieval, however, it doesn't retrieve the primary key columns first, it retrieves them in the Hashtable order. Is there any reason for this, or can I submit a patch that causes the retrieval order to match the SELECT column order? There are numerous workarounds, from changing the name of the pk columns until the hash causes them to come out first (a flaky hack) to changing the JDBC driver, but this since the Microsoft driver is likely to be come the default for SQL Server installations it strikes me as an important compatability issue. Incidentally, lines 215-221 don't seem to have any effect, nor have they done since they were written. Am I just on crack? -- >Comment By: Dan Christopherson (danch) Date: 2002-04-16 18:20 Message: Logged In: YES user_id=51915 fixed, courtesy patch#520200 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517062&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Comments inlined... > I agree that there should be a single definitive user-specified list of > what should be deployed, but I think it belongs in the ant build file that > constructs what gets deployed. To me, it is more sloppy to include stuff > in your package that you don't want deployed than to deploy everything in a > package. As an example of why this is useful, let me outline my companies development environment: Our cvs repository is itself an exploded ear file, plus an src directory, the ant build scripts, minus any compiled code. We have 3 war archives, and a single ejb-jar file. The ant scripts simply compile the appropriate source files to the propper directories (WEB-INF/classes, the ejb-jar, etc...). In development, this directory is directly deployed by JBoss. Another ant task builds the compressed archives for production (stripping out the src, build scripts, etc...), but development is done directly within the deployed application. This has improved the speed of developing / redeploying / testing dramatically. (Perhaps this gives you an idea why I have been so hung up on exploded deployment ;-) ) To remove an archive from our deployment would meen removing an entire CVS directory. > The original motivation behind the unified classloader was to make it > practical to work on giant applications that are manageable only if they > are packed into multiple ears, but which need to refer to each other's > classes, and which need to be independently redeployable. A tree-based > classloader scheme isn't going to work for this. I'm not suggesting getting rid of this. In fact, I like the convenience of not specifying Class-Path entries all over my META-INF files, and I think the spec should allow shared classpaths. But, it should be recognized that any user who makes use of this feature may need to make some configuration changes if they switch app servers. > I have never understood what the purpose of the classpath entries inside an > ear really was, nor the problems with deploying "everything in sight". It just takes control away from the user, though it could be argued that the user doesn't have to include things she does not want deployed. > To me, your problem seems like it is based on your convenience and way of > working rather than an intrinsic problem with "everything". I could be > missing something, please let me know what. No, my problem is with an app-server making assumptions that a user may not want. Further, the user has no way of overriding these assumptions. Put simply: JBoss is violating the J2EE specification here. Consider the following, legal ear archive: 2 nested war files, who use the same web-context, but only the first specified in application.xml. JBoss will not be able to deploy this because of the context root conflict, however a compliant app server would. > Also, we still need to deploy every .sar inside a j2ee package unless we > want to add a jboss-specific dd to every package indicating which sars get > deployed. I think adding a dd just for this is silly. Yeah, a bit silly, but IMO better than what we have now. I would prefer a documented convention stating what directory within a sar archive nested deployments should live. The same goes for rar files. (Kind of like war files - they have the WEB-INF/lib and WEB-INF/classes directories). > Did you change the behavior of deploying sars or are all of them still deployed? No - I got yelled at when I tried :-) Everything works exactly as it did, except the EARDeployer, and I will submit a patch to revert this functionality if required. > Anyway for ears I guess looking at application.xml should be ok since the > user has to include it anyway. Sorry for rambling, and I hope I'm not coming off too strongly. Thanks for listening! -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntityCommand.java
User: danch
Date: 02/04/16 16:10:17
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCLoadEntityCommand.java
Log:
merged patch #520200 for bug 517062 (resultset column ordering)
Revision ChangesPath
No revision
No revision
1.11.2.3 +248 -241
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
Index: JDBCLoadEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java,v
retrieving revision 1.11.2.2
retrieving revision 1.11.2.3
diff -u -r1.11.2.2 -r1.11.2.3
--- JDBCLoadEntityCommand.java14 Jul 2001 21:43:24 - 1.11.2.2
+++ JDBCLoadEntityCommand.java16 Apr 2002 23:10:17 - 1.11.2.3
@@ -1,241 +1,248 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.ejb.plugins.jaws.jdbc;
-
-import java.lang.reflect.Field;
-import java.lang.reflect.Method;
-
-import java.util.Iterator;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.HashMap;
-
-import java.rmi.NoSuchObjectException;
-import java.rmi.RemoteException;
-import java.rmi.ServerException;
-
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
-
-import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.jaws.JAWSPersistenceManager;
-import org.jboss.ejb.plugins.jaws.JPMLoadEntityCommand;
-import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.JawsEntityMetaData;
-
-/**
- * JAWSPersistenceManager JDBCLoadEntityCommand
- *
- * @see
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
- * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @author mailto:[EMAIL PROTECTED]";>Joe Shevland
- * @author mailto:[EMAIL PROTECTED]";>Justin Forder
- * @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
- * @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson)
- * @version $Revision: 1.11.2.2 $
- */
-public class JDBCLoadEntityCommand
- extends JDBCQueryCommand
- implements JPMLoadEntityCommand
-{
- /**what is the position of each cmp field in the generated select statement?
-* this simply maps the position of the field in the CMP list to its position
-* in the generated select statement. This is neccessary because of the variable
-* number of key columns (which are skipped in a load) and because there can
-* be overlap between the two: pkfields and cmpfields are neither disjoint sets
-* nor is the cmpfields a subset of pkfields (not that that makes sense to
-* me right now, but I'll roll with it until I have more chance to analyse -
danch)
-*/
- int [] cmpFieldPositionInSelect = null;
-
- /** This const is used in places where I need to add an offset to a count
-* to account for the fact that JDBC counts from one whilst every other
-* damn thing in the languase starts at 0, the way God intended!
-*/
- private static final int JDBC_WART_OFFSET = 1;
- // Constructors --
-
- public JDBCLoadEntityCommand(JDBCCommandFactory factory)
- {
- super(factory, "Load");
-
- String sql = createSelectClause() + " FROM " + jawsEntity.getTableName()
- + " WHERE " + getPkColumnWhereList();
- if (jawsEntity.hasSelectForUpdate())
- {
- sql += " FOR UPDATE";
- }
-
- setSQL(sql);
- }
-
- protected String createSelectClause() {
- // Select SQL
- String sql = "SELECT ";
- HashMap alreadyListed = new HashMap();
- // put the key fields in first
- // we'll stash the column names here so that we can later map an overlapped
- // column (overlap between PK and CMP) into its spot in the select statement.
- String[] pkColumnNames = new String[jawsEntity.getNumberOfPkFields()];
- Iterator keyIt = jawsEntity.getPkFields();
- int fieldCount = 0;
- while (keyIt.hasNext())
- {
- PkFieldMetaData pkField = (PkFieldMetaData)keyIt.next();
-
- sql += ((fieldCount==0) ? "" : ",") +
-jawsEntity.getTableName() + "." + pkField.getColumnName();
- alreadyListed.put(pkField.getColumnName().toUpperCase(), pkField);
- pkColumnNames[fieldCount]=pkField.getColumnName();
- fieldCount++;
- }
-
- cmpFieldPositionInSelect = new int[jawsEntity.getNumberOfCMPFields()];
- Iterator it = jawsEntity.getCMPFields();
- int cmpFieldCount = 0
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb CMPFindTestSession.java
User: danch
Date: 02/04/16 16:06:03
Modified:src/main/org/jboss/test/readahead/ejb Tag: Branch_2_4
CMPFindTestSession.java
Log:
Fixed a bug that was causing tests to error out - seems we're fast enough to insert
> 1 entity in the windows currentTimeMillis resolution
Revision ChangesPath
No revision
No revision
1.1.2.3 +172 -172
jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java
Index: CMPFindTestSession.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- CMPFindTestSession.java 29 Oct 2001 00:04:26 - 1.1.2.2
+++ CMPFindTestSession.java 16 Apr 2002 23:06:03 - 1.1.2.3
@@ -1,172 +1,172 @@
-package org.jboss.test.readahead.ejb;
-
-import java.util.Iterator;
-import java.util.Collection;
-import java.text.Collator;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-import javax.ejb.EJBException;
-import javax.ejb.SessionBean;
-import javax.ejb.SessionContext;
-import org.jboss.test.readahead.interfaces.AddressHome;
-import org.jboss.test.readahead.interfaces.AddressRemote;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityHome;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityRemote;
-
-/**
- * Implementation class for session bean used in read-ahead finder
- * tests
- *
- * @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
- * @version $Id: CMPFindTestSession.java,v 1.1.2.2 2001/10/29 00:04:26 danch Exp $
- *
- * Revision:
- */
-public class CMPFindTestSession implements SessionBean {
- private static final int DATASET_SIZE = 100;
-
- private SessionContext sessionContext;
-
- public void ejbCreate() {
- }
- public void ejbRemove() {
- }
- public void ejbActivate() {
- }
- public void ejbPassivate() {
- }
- public void setSessionContext(SessionContext context) {
- sessionContext = context;
- }
-
- public void removeTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup("CMPFindTestEntity");
-
- Collection coll = home.findAll();
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-
-rem.remove();
- }
- } catch (Exception e) {
- }
- }
-
- public void createTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup("CMPFindTestEntity");
- AddressHome addrHome = (AddressHome)ctx.lookup("Address");
- for (int i=0;i=0)
- throw new EJBException("Ordering of findAll failed:
"+lastName+"<"+thisName);
-//System.out.println("lastName=<"+lastName+">,
thisName=<"+thisName+">");
-//System.out.println("Name: "+rem.getName()+" Rank: "+rem.getRank());
-lastName = thisName;
-count++;
- }
- long endTime = System.currentTimeMillis();
- System.out.println("called "+count+" beans in "+(endTime-startTime)+"
ms.");
- } catch (Exception e) {
- }
- }
-
- public void testUpdates() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup("CMPFindTestEntity");
-
- long startTime = System.currentTimeMillis();
- Collection coll = home.findAll();
- int count = 0;
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-rem.getName();
-rem.setRank("Very");
-count++;
- }
- long endTime = System.currentTimeMillis();
- System.out.println("called "+count+" beans in "+(endTime-startTime)+"
ms.");
- } catch (Exception e) {
- }
- }
-}
\ No newline at end of file
+package org.jboss.test.readahead.ejb;
+
+import java.util.Iterator;
+import java.util.Collection;
+import java.text.Collator;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+import javax.ejb.EJBException;
+import javax.ejb.SessionBean;
+import javax.ejb.SessionContext;
+import org.jboss.test.readahead.interfaces.AddressHome;
+import org.jboss.test.readahead.interfaces.AddressRemote;
+import org.jboss.test.readahead.interfaces.CMPFindTestEntityHome;
[JBoss-dev] CVS update: jbosstest build.xml
User: patriot1burke Date: 02/04/16 15:47:18 Modified:.build.xml Log: forgot to add an interface to the testbeancluster.jar. This was causing this unit test to fail badly. Revision ChangesPath 1.107 +2 -1 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.106 retrieving revision 1.107 diff -u -r1.106 -r1.107 --- build.xml 15 Apr 2002 02:48:53 - 1.106 +++ build.xml 16 Apr 2002 22:47:18 - 1.107 @@ -13,7 +13,7 @@ - + @@ -1722,6 +1722,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
I agree that there should be a single definitive user-specified list of what should be deployed, but I think it belongs in the ant build file that constructs what gets deployed. To me, it is more sloppy to include stuff in your package that you don't want deployed than to deploy everything in a package. The original motivation behind the unified classloader was to make it practical to work on giant applications that are manageable only if they are packed into multiple ears, but which need to refer to each other's classes, and which need to be independently redeployable. A tree-based classloader scheme isn't going to work for this. I have never understood what the purpose of the classpath entries inside an ear really was, nor the problems with deploying "everything in sight". To me, your problem seems like it is based on your convenience and way of working rather than an intrinsic problem with "everything". I could be missing something, please let me know what. Also, we still need to deploy every .sar inside a j2ee package unless we want to add a jboss-specific dd to every package indicating which sars get deployed. I think adding a dd just for this is silly. Did you change the behavior of deploying sars or are all of them still deployed? Anyway for ears I guess looking at application.xml should be ok since the user has to include it anyway. Thanks david jencks On 2002.04.16 18:17:39 -0400 lsanders wrote: > The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested > ejb-jar's and war's should share classes, and it is all based on > Class-Path > Manifest entries. Technically, per spec, nested archives should never > share > Classpath's unless there is a Class-Path META-INF entry (i.e. web > archives > should not, by default, be able to see ejb-jar files within the same ear > archive). > > JBoss takes a more conservative approach, and gives each deployment > access > to each other's information. This sacrifices archive interoperability > for > ease of use. > > The patch I put forward took a middle of the road approach - only those > archives specified in application.xml are deployed, but they can all > access > each others data without Class-Path entries. I like being able to limit > the > deployments by commenting out portions of my application.xml. I use this > all the time when testing within an exploded archive - it allows me to > isolate one portion of development. > > Personally, I don't like the "deploy everything" philosophy. It just > seems > sloppy to me. I don't like it within sars, rars, or anything else. > There > should be a single, definitive, user-specified list of exactly what > should > be deployed, and when. The idea of: "search through every single file > within an archive, and check to see if it is deployable" leads to hacks > like > the one currently in MainDeployer: "... unless it is a war file, then let > the war deployer figure it out". > > -Larry > > > Hmmm, I thought that might be what the spec wanted, but when I read it > I > > decided it was consistent with "put everything in sight on the > classpath" > > since then everything they mention is definitely on the classpath. > Maybe > > we need a configuration switch? What problems come from "everything in > > sight?" If you have server-specific jars, you'd need to change the ear > > anyway to change which are deployed, so why not take out the packages > you > > don't want deployed? > > > > Any other thoughts? > > > > david jencks > > > > On 2002.04.16 17:01:13 -0400 lsanders wrote: > > > It was my patch that changed this. I changed the EARDeployer to only > > > deploy > > > those applications listed in an application.xml file (I believe that > this > > > was another bug on sourceforge?). The struts.jar should only be > included > > > on > > > the classpath if it is an application in the application.xml file, if > it > > > is > > > in the WEB-INF/lib, or if it is listed in a Class-Path entry in the > > > META-INF > > > file. I believe this is how the spec defines things. Is this right? > > > > > > -Larry > > > > > > > > > > Bugs item #544848, was opened at 2002-04-16 15:19 > > > > You can respond by visiting: > > > > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > > > 22866 > > > > > > > > Category: None > > > > Group: v3.0 Rabbit Hole > > > > Status: Open > > > > Resolution: None > > > > Priority: 5 > > > > Submitted By: Peter Luttrell (objec) > > > > Assigned to: Nobody/Anonymous (nobody) > > > > Summary: EAR Deployments don't work the same > > > > > > > > Initial Comment: > > > > with jboss3.0rc1 with tomcat4.0.3 if I create an ear > > > > file such as this: > > > > > > > > one.war > > > > two.war > > > > struts.jar > > > > META-INF/application.xml > > > > > > > > where one.war and two.war depend on structs.jar, jboss > > > > blows up when one.war attempts to preload the structs > > > > servlet. > > > > > > > > with jboss3.0b1 with tomcat4.0.3, th
[JBoss-dev] CVS update: jbosstest build.xml
User: patriot1burke Date: 02/04/16 15:45:34 Modified:.Tag: Branch_3_0 build.xml Log: forgot to add an interface to the testbeancluster.jar. This was causing this unit test to fail badly. Revision ChangesPath No revision No revision 1.106.2.1 +2 -1 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.106 retrieving revision 1.106.2.1 diff -u -r1.106 -r1.106.2.1 --- build.xml 15 Apr 2002 02:48:53 - 1.106 +++ build.xml 16 Apr 2002 22:45:34 - 1.106.2.1 @@ -13,7 +13,7 @@ - + @@ -1721,6 +1721,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config solid-service.xml jdatastore-service.xml
User: d_jencks Date: 02/04/16 15:22:09 Added: src/etc/example-config Tag: Branch_3_0 solid-service.xml jdatastore-service.xml Log: ported configs back from main Revision ChangesPath No revision No revision 1.1.2.1 +0 -0 jbosscx/src/etc/example-config/solid-service.xml Index: solid-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/solid-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 jbosscx/src/etc/example-config/jdatastore-service.xml Index: jdatastore-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/jdatastore-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/test DeployServiceUnitTestCase.java
User: d_jencks
Date: 02/04/16 15:26:32
Modified:src/main/org/jboss/test/jmx/test Tag: Branch_3_0
DeployServiceUnitTestCase.java
Log:
ported test fixes back from main
Revision ChangesPath
No revision
No revision
1.13.2.1 +3 -5
jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java
Index: DeployServiceUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- DeployServiceUnitTestCase.java7 Apr 2002 05:25:59 - 1.13
+++ DeployServiceUnitTestCase.java16 Apr 2002 22:26:32 - 1.13.2.1
@@ -31,7 +31,7 @@
/**
* @see
* @authormailto:[EMAIL PROTECTED]";>David Jencks
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.13.2.1 $
*/
public class DeployServiceUnitTestCase
extends JBossTestCase
@@ -140,8 +140,6 @@
ObjectName testObjectName = new ObjectName("test:name=TestDeployer");
ObjectName testObjectName2 = new ObjectName("test:name=TestDeployer2");
ObjectName testObjectName3 = new ObjectName("test:name=TestDeployer3");
- //the classloader mbean
- ObjectName classLoaderObjectName = new
ObjectName("jboss.system:service=ServiceClassLoader");
//check they aren't there already
assertTrue("test mbean already registered before deploy",
!getServer().isRegistered(testObjectName));
@@ -154,7 +152,7 @@
//make sure we can create an mbean based on the class we just deployed.
try
{
- getServer().createMBean("org.jboss.test.jmx.mbean.TestDeployer",
testObjectName2, classLoaderObjectName);
+ getServer().createMBean("org.jboss.test.jmx.mbean.TestDeployer",
testObjectName2);
}
catch (Exception e)
{
@@ -185,7 +183,7 @@
//check the class is not available
try
{
- ObjectInstance oe =
getServer().createMBean("org.jboss.test.jmx.mbean.TestDeployer", testObjectName3,
classLoaderObjectName);
+ ObjectInstance oe =
getServer().createMBean("org.jboss.test.jmx.mbean.TestDeployer", testObjectName3);
fail("created mbean when class should not be present: object instance: " +
oe);
}
catch (ReflectionException re)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx test-service.xml
User: d_jencks Date: 02/04/16 15:26:32 Modified:src/resources/jmx Tag: Branch_3_0 test-service.xml Log: ported test fixes back from main Revision ChangesPath No revision No revision 1.6.2.1 +2 -2 jbosstest/src/resources/jmx/test-service.xml Index: test-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/test-service.xml,v retrieving revision 1.6 retrieving revision 1.6.2.1 diff -u -r1.6 -r1.6.2.1 --- test-service.xml 7 Apr 2002 05:25:59 - 1.6 +++ test-service.xml 16 Apr 2002 22:26:32 - 1.6.2.1 @@ -34,7 +34,7 @@ UserName java.lang.String - + sa Password @@ -66,7 +66,7 @@ jboss.jca:service=CachedConnectionManager -java:/jaas/DefaultDbRealm + java:/TransactionManager ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested ejb-jar's and war's should share classes, and it is all based on Class-Path Manifest entries. Technically, per spec, nested archives should never share Classpath's unless there is a Class-Path META-INF entry (i.e. web archives should not, by default, be able to see ejb-jar files within the same ear archive). JBoss takes a more conservative approach, and gives each deployment access to each other's information. This sacrifices archive interoperability for ease of use. The patch I put forward took a middle of the road approach - only those archives specified in application.xml are deployed, but they can all access each others data without Class-Path entries. I like being able to limit the deployments by commenting out portions of my application.xml. I use this all the time when testing within an exploded archive - it allows me to isolate one portion of development. Personally, I don't like the "deploy everything" philosophy. It just seems sloppy to me. I don't like it within sars, rars, or anything else. There should be a single, definitive, user-specified list of exactly what should be deployed, and when. The idea of: "search through every single file within an archive, and check to see if it is deployable" leads to hacks like the one currently in MainDeployer: "... unless it is a war file, then let the war deployer figure it out". -Larry > Hmmm, I thought that might be what the spec wanted, but when I read it I > decided it was consistent with "put everything in sight on the classpath" > since then everything they mention is definitely on the classpath. Maybe > we need a configuration switch? What problems come from "everything in > sight?" If you have server-specific jars, you'd need to change the ear > anyway to change which are deployed, so why not take out the packages you > don't want deployed? > > Any other thoughts? > > david jencks > > On 2002.04.16 17:01:13 -0400 lsanders wrote: > > It was my patch that changed this. I changed the EARDeployer to only > > deploy > > those applications listed in an application.xml file (I believe that this > > was another bug on sourceforge?). The struts.jar should only be included > > on > > the classpath if it is an application in the application.xml file, if it > > is > > in the WEB-INF/lib, or if it is listed in a Class-Path entry in the > > META-INF > > file. I believe this is how the spec defines things. Is this right? > > > > -Larry > > > > > > > Bugs item #544848, was opened at 2002-04-16 15:19 > > > You can respond by visiting: > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > > 22866 > > > > > > Category: None > > > Group: v3.0 Rabbit Hole > > > Status: Open > > > Resolution: None > > > Priority: 5 > > > Submitted By: Peter Luttrell (objec) > > > Assigned to: Nobody/Anonymous (nobody) > > > Summary: EAR Deployments don't work the same > > > > > > Initial Comment: > > > with jboss3.0rc1 with tomcat4.0.3 if I create an ear > > > file such as this: > > > > > > one.war > > > two.war > > > struts.jar > > > META-INF/application.xml > > > > > > where one.war and two.war depend on structs.jar, jboss > > > blows up when one.war attempts to preload the structs > > > servlet. > > > > > > with jboss3.0b1 with tomcat4.0.3, the above > > > configuration worked perfectly. > > > > > > was this intentionally changed? or is it a bug? > > > > > > if i use the "Class-Path" entry to specify the > > > structs.jar file in the manifest file for both one.war > > > and two.war it also works. I've only tested this on > > > rc1. > > > > > > -- > > > > > > You can respond by visiting: > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > > 22866 > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config mysql-service.xml
User: d_jencks Date: 02/04/16 15:13:18 Modified:src/etc/example-config Tag: Branch_3_0 mysql-service.xml Log: merge change back from MAIN Revision ChangesPath No revision No revision 1.1.2.1 +2 -2 jbosscx/src/etc/example-config/mysql-service.xml Index: mysql-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/mysql-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- mysql-service.xml 8 Apr 2002 15:37:55 - 1.1 +++ mysql-service.xml 16 Apr 2002 22:13:18 - 1.1.2.1 @@ -30,7 +30,7 @@ ConnectionURL java.lang.String - jdbc:mysql://dell:/jbossdb + jdbc:mysql://dell:3306/jbossdb DriverClass @@ -50,7 +50,7 @@ -DefaultDS +MySqlDS ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ Memory Leak
Hi Hiram I just heared from a customer that they found a memory leak in JBossMQ with a profiler. He promised to send information about it soon I am also working on a long term test. Because of that I will create a marathon test case for JBossMQ in the next days to investigate this issue further. So I will let you know as soon as I get more information. Andy x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
> > >-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB > -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton > Any reason why the service can not set these props? >If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to >the classpath. > Why the special case for IBM? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Are we logging the exception enough!!!
Title: RE: [JBoss-dev] Are we logging the exception enough!!! It's funny, I was just emailing David about a good starting point for contributing. Not sure if I have the time or knowledge of the framework, but I'll take a day or two digging around to see if the scope is a good fit for me. -Casey -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:05 PM To: David Jencks; Scott M Stark Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Are we logging the exception enough!!! he he, funny I want a new developer that wants to get RW and prove he brings something to take it though. I would formulate the project like jason did and put it on the website see if someone takes it. (or someone lurking on this list speak up). It is big and gives you an overview of many classes. marcf |Naaah... we need to log it several times within the same object!!! Any |exception should fill up your hard drive with the log file!! | |I'll take a look at fixing this. |thanks |david jencks | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Hmmm, I thought that might be what the spec wanted, but when I read it I decided it was consistent with "put everything in sight on the classpath" since then everything they mention is definitely on the classpath. Maybe we need a configuration switch? What problems come from "everything in sight?" If you have server-specific jars, you'd need to change the ear anyway to change which are deployed, so why not take out the packages you don't want deployed? Any other thoughts? david jencks On 2002.04.16 17:01:13 -0400 lsanders wrote: > It was my patch that changed this. I changed the EARDeployer to only > deploy > those applications listed in an application.xml file (I believe that this > was another bug on sourceforge?). The struts.jar should only be included > on > the classpath if it is an application in the application.xml file, if it > is > in the WEB-INF/lib, or if it is listed in a Class-Path entry in the > META-INF > file. I believe this is how the spec defines things. Is this right? > > -Larry > > > > Bugs item #544848, was opened at 2002-04-16 15:19 > > You can respond by visiting: > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > 22866 > > > > Category: None > > Group: v3.0 Rabbit Hole > > Status: Open > > Resolution: None > > Priority: 5 > > Submitted By: Peter Luttrell (objec) > > Assigned to: Nobody/Anonymous (nobody) > > Summary: EAR Deployments don't work the same > > > > Initial Comment: > > with jboss3.0rc1 with tomcat4.0.3 if I create an ear > > file such as this: > > > > one.war > > two.war > > struts.jar > > META-INF/application.xml > > > > where one.war and two.war depend on structs.jar, jboss > > blows up when one.war attempts to preload the structs > > servlet. > > > > with jboss3.0b1 with tomcat4.0.3, the above > > configuration worked perfectly. > > > > was this intentionally changed? or is it a bug? > > > > if i use the "Class-Path" entry to specify the > > structs.jar file in the manifest file for both one.war > > and two.war it also works. I've only tested this on > > rc1. > > > > -- > > > > You can respond by visiting: > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > 22866 > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) >Summary: EAR Deployments don't work Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the "Class-Path" entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- >Comment By: Peter Luttrell (objec) Date: 2002-04-16 16:35 Message: Logged In: YES user_id=472835 when I mentioned that if I use the Class-Path in the war it worked, i meant that the deployment didn't throw any exceptions. however when I actually go to a page that requires classes in the jar, tomcat blows up indicating that it cannot find them. This may be a seperate issue - let me know if you want me to post another issue about it. the work around at this point is just include the struts.jar in both war files. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS with JBossMQ over high latency links
Hi, guys I posted this on JMS/JBossMQ forum but it seems that posting to jboss-dev will make this issue more visible. We are trying to run an MDB that listens to a Topic on a remote JMS provider which resides across a high latency link. The behavior we encountered was that with relatively high load (about 10 or so messages/sec) the delay for all messages to reach the MDB gets to be very, very large. (We are using the 'fastest' of the IL -- OIL) I dug into the Source and realized that, perhaps, this is due to the fact that all methods that ServerIL and ClientIL interfaces expose end up being synchronized in the OIL implementation. Judging from the source, this is because in OIL you have to stuff everything down a single socket and since multiple threads have access to a JMS Connection and it has to be thread safe, synchronizing is a reasonable solution. On high latency links this is a killer, though. I am wondering how much work would it involve to write an extended OIL which can use a socket pool or something of that sort to multiplex communications better. What do you say? Anatoly Akkerman. * * * View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=13074 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Are we logging the exception enough!!!
he he, funny I want a new developer that wants to get RW and prove he brings something to take it though. I would formulate the project like jason did and put it on the website see if someone takes it. (or someone lurking on this list speak up). It is big and gives you an overview of many classes. marcf |Naaah... we need to log it several times within the same object!!! Any |exception should fill up your hard drive with the log file!! | |I'll take a look at fixing this. |thanks |david jencks | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry > Bugs item #544848, was opened at 2002-04-16 15:19 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= 22866 > > Category: None > Group: v3.0 Rabbit Hole > Status: Open > Resolution: None > Priority: 5 > Submitted By: Peter Luttrell (objec) > Assigned to: Nobody/Anonymous (nobody) > Summary: EAR Deployments don't work the same > > Initial Comment: > with jboss3.0rc1 with tomcat4.0.3 if I create an ear > file such as this: > > one.war > two.war > struts.jar > META-INF/application.xml > > where one.war and two.war depend on structs.jar, jboss > blows up when one.war attempts to preload the structs > servlet. > > with jboss3.0b1 with tomcat4.0.3, the above > configuration worked perfectly. > > was this intentionally changed? or is it a bug? > > if i use the "Class-Path" entry to specify the > structs.jar file in the manifest file for both one.war > and two.war it also works. I've only tested this on > rc1. > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= 22866 > > ___ > 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] Re: What can change in rc1?
Yes, these are fine. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: "jboss-dev" <[EMAIL PROTECTED]>; "Scott Stark" <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 1:57 PM Subject: What can change in rc1? > Just to make sure I understand... > > I can change in rc1: > > bug fixes, especially those that improve testsuite results (also fix in > main) > > additional comments, especially those that make it into generated jmx-api > documentation (also in main) > > additional sample db config files (also in main) > > - > > Any design changes no matter how trivial I think they are should be > reserved for main. > > Agreed? > > Thanks > david jencks > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
I changed run.sh to add the properties JacORB needs: -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to the classpath. These changes allow you to start an iiop-enabled server without passing any switches to run.sh. This should be good for automatic testing, I presume. (I would really like to see the iiop testcases running successfully at lubega.) Please let me know if there is a better way to accomplish this. Thanks, Francisco PS: I removed the iiop stuff from jboss-service.xml and moved it to a separate service, as Bill and Scott indicated. It worked perfectly. On Tue, 16 Apr 2002, Jason Dillon wrote: > Why runs.sh... this is what was concerned about. Can you please explain this. > > --jason > > > Quoting Francisco Reverbel <[EMAIL PROTECTED]>: > > > Yes, the iiop stuff is now generated by a default build. > > > > I have changed a couple of files (jboss-services.xml and run.sh) > > in order to run it. Please see the patchfile attached. > > > > Should I commit these changes? > > > > Cheers, > > > > Francisco > > > > PS: David Jencks is getting a very strange error from rmic. > > Are you also getting this error? > > > > On Mon, 15 Apr 2002, Jason Dillon wrote: > > > > > I setup the build system to include jboss.net & iiop in the default > > > builds. Please look at the configuration that is generated and make > > > sure that iiop stuff will work with a default build. > > > > > > Note, this is on HEAD. > > > > > > --jason > > > > > > > > > Francisco Reverbel wrote: > > > > > > >Will it include the iiop stuff? Jason and I were talking about > > > >making it part of the default build. > > > > > > > >User feedback would be a good thing for me at this point. > > > > > > > >Best, > > > > > > > >Francisco > > > > > > > >On Sun, 14 Apr 2002, Scott M Stark wrote: > > > > > > > >>I'm creating the 3.0 branch for the RC1 release at midnight > > > >>(GMT-0700). Do not commit any changes to main after > > > >>22:00 -0700 until the branch is announced to be complete. > > > >> > > > >> > > > >>Scott Stark > > > >>Chief Technology Officer > > > >>JBoss Group, LLC > > > >> > > > >> > > > >> > > > >> > > > >>___ > > > >>Jboss-development mailing list > > > >>[EMAIL PROTECTED] > > > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >> > > > > > > > > > > > > > > > > > > > > - > This mail sent through IMP: http://horde.org/imp/ > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] What can change in rc1?
Just to make sure I understand... I can change in rc1: bug fixes, especially those that improve testsuite results (also fix in main) additional comments, especially those that make it into generated jmx-api documentation (also in main) additional sample db config files (also in main) - Any design changes no matter how trivial I think they are should be reserved for main. Agreed? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Are we logging the exception enough!!!
Naaah... we need to log it several times within the same object!!! Any exception should fill up your hard drive with the log file!! I'll take a look at fixing this. thanks david jencks On 2002.04.16 16:22:41 -0400 Scott M Stark wrote: > The following exception is getting logged by the > StatelessSessionContainer, > the EjbModule, and finally the MainDeployer 3 times, and this is overkill > in > my > book. If an exception is being thrown or rethrown I don't think it should > be > logged unless trace level logging is enabled. The MainDeployer could > better > handle reporting the failure of a nested deployment so that redundant > logging > does not occur. > > 13:00:07,937 WARN [EjbModule] you are using deprecated > JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory > 13:00:07,953 ERROR [StatelessSessionContainer] Exception in service > lifecyle > operation: create > org.jboss.deployment.DeploymentException: There are no home interface > interceptors configured > at > org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 > 6) > at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) > at > org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav > a:175) > at org.jboss.ejb.Container.invoke(Container.java:790) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:867) > at $Proxy0.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:271) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy18.create(Unknown Source) > at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) > at > org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:867) > at $Proxy0.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:271) > at > org.jboss.system.ServiceController.create(ServiceController.java:211) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy5.create(Unknown Source) > at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) > at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) > at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy4.deploy(Unknown Source) > at > org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne > r.java:350) > at > org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen > tScanner.java:530) > at > org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. > java:410) > at > org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(Ab > stractDeploymentScanner.java:202) > at > org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(Abs > tractDeploymentScanner.java:191) > > 13:00:08,062 WARN [ServiceController] Ignoring request to destroy > non-existant > service: jboss.j2ee:service=EJB,jndiName=tomcat-test/Optimized > 13:00:08,062 INFO [EjbModule] Remove JSR-77 EJB Module: > jboss.management.single:J2EEApplication=tomcat-test.ear,J2EEServer=Single,j2 > eeType=EJBModule,name=tomca > t-test.jar > 13:00:08,078 ERROR [EjbModule] Initialization failed > org.jboss.deployment.DeploymentException: There are no home interface > interceptors configured > at > org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(Pr
Re: [JBoss-dev] Are we logging the exception enough!!!
Sounds like MainDeployer should be the one to log this exception. I have noticed that we generally misuse exceptions in many places... ie. catching exceptions to log, then rethrow, or just to ignore. There are also places where we wrap exceptions when we could really just add a checked Exception to the method and let higher level logic handle the failure. This was the case with ServiceMBeanSupport.stopService() in previous releases. I changed this to declare a checked Exception which simplifies implementing services, as they don't need to handle the exceptions that occu here, the support class does that for you. Anyways, my point is that I think we can clean up our exception/throwable usage significantly. Doing so will simplify code which is current handling some exceptions as well as make it easier to debug, as we won't have a billon traces for a single exception. It is a big job though... to clean this up, which is why I think it has not been attempted before. We might also want to provide a guide for new developers on how to deal with exception coding, as it seems to be a common problem. --jason Quoting Scott M Stark <[EMAIL PROTECTED]>: > The following exception is getting logged by the StatelessSessionContainer, > the EjbModule, and finally the MainDeployer 3 times, and this is overkill > in > my > book. If an exception is being thrown or rethrown I don't think it should > be > logged unless trace level logging is enabled. The MainDeployer could better > handle reporting the failure of a nested deployment so that redundant > logging > does not occur. > > 13:00:07,937 WARN [EjbModule] you are using deprecated > JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory > 13:00:07,953 ERROR [StatelessSessionContainer] Exception in service > lifecyle > operation: create > org.jboss.deployment.DeploymentException: There are no home interface > interceptors configured > at > org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 > 6) > at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) > at > org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav > a:175) > at org.jboss.ejb.Container.invoke(Container.java:790) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:867) > at $Proxy0.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:271) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy18.create(Unknown Source) > at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) > at > org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:867) > at $Proxy0.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:271) > at > org.jboss.system.ServiceController.create(ServiceController.java:211) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy5.create(Unknown Source) > at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) > at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) > at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy4.deploy(Unknown Source) > at > org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne > r.java:350) > at > org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeployme
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy ClientContainer.java
User: starksm
Date: 02/04/16 13:39:32
Modified:src/main/org/jboss/proxy ClientContainer.java
Log:
Remove the commented out imports
Revision ChangesPath
1.2 +4 -24 jboss/src/main/org/jboss/proxy/ClientContainer.java
Index: ClientContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ClientContainer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClientContainer.java 7 Mar 2002 18:20:49 - 1.1
+++ ClientContainer.java 16 Apr 2002 20:39:32 - 1.2
@@ -20,29 +20,9 @@
import org.jboss.invocation.Invocation;
import org.jboss.invocation.InvocationContext;
-/*
-import javax.transaction.TransactionManager;
-import java.security.Principal;
-import javax.transaction.Transaction;
-import javax.transaction.SystemException;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-import javax.ejb.EJBObject;
-import javax.ejb.EJBHome;
-import java.rmi.RemoteException;
-
-import org.jboss.proxy.ejb.ReadAheadBuffer;
-import org.jboss.proxy.ejb.ListEntityProxy;
-import org.jboss.invocation.Invocation;
-import org.jboss.invocation.Invoker;
-import org.jboss.tm.TransactionPropagationContextFactory;
-import org.jboss.security.SecurityAssociation;
-*/
-
/**
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* 2001/11/19: marcf
*
@@ -50,7 +30,7 @@
*
*/
public class ClientContainer
-implements Externalizable, InvocationHandler
+ implements Externalizable, InvocationHandler
{
// the "static" information that gets attached to every invocation
@@ -104,7 +84,7 @@
}
public void writeExternal(final ObjectOutput out)
- throws IOException
+ throws IOException
{
out.writeObject(next);
out.writeObject(context);
@@ -119,7 +99,7 @@
* @throws ClassNotFoundException
*/
public void readExternal(final ObjectInput in)
- throws IOException, ClassNotFoundException
+ throws IOException, ClassNotFoundException
{
next = (Interceptor) in.readObject();
context = (InvocationContext) in.readObject();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/session DistributedHttpSessionManager.java
User: jules_gosnell
Date: 02/04/16 13:29:57
Modified:jetty/src/main/org/jboss/jetty/session
DistributedHttpSessionManager.java
Log:
logging changes
Revision ChangesPath
1.14 +10 -6
contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java
Index: DistributedHttpSessionManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DistributedHttpSessionManager.java14 Feb 2002 01:03:16 - 1.13
+++ DistributedHttpSessionManager.java16 Apr 2002 20:29:57 - 1.14
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16 jules_gosnell
Exp $
+// $Id: DistributedHttpSessionManager.java,v 1.14 2002/04/16 20:29:57 jules_gosnell
Exp $
// TODO
@@ -118,6 +118,8 @@
class IntervalSnapshotStrategy
extends SnapshotStrategy
{
+ static final Logger _log=Logger.getLogger("IntervalSnapshotStrategy");
+
static class
TimeOutHelper
implements AbstractTimeOutManager.TimeOutHelper
@@ -126,7 +128,7 @@
timeOut(Object object)
{
IntervalSnapshotStrategy iss=(IntervalSnapshotStrategy)object;
- System.out.println("snapshotting HttpSessions for Context
("+iss._manager.getServletContext().getServletContextName()+")");
+ _log.info("snapshotting HttpSessions for Context
("+iss._manager.getServletContext().getServletContextName()+")");
iss._manager.snapshot(iss._notifyActivate, iss._notifyPassivate); //
should probably be done on another thread
iss._timer.reregister(iss, System.currentTimeMillis(), iss._interval*1000);
}
@@ -179,14 +181,16 @@
//--
-class MyTimeOutHelper
+class DistributedHttpSessionTimer
implements AbstractTimeOutManager.TimeOutHelper
{
+ static final Logger _log=Logger.getLogger("DistributedHttpSessionTimer");
+
public void
timeOut(Object object)
{
DistributedHttpSession session=(DistributedHttpSession)object;
-System.out.println("session ("+session.getId()+") timed out - cleaning up");
+_log.info("session ("+session.getId()+") timed out - cleaning up");
session.getManager().destroyHttpSession(session);
}
@@ -201,7 +205,7 @@
//--
/**
*
- * @version $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16
jules_gosnell Exp $
+ * @version $Id: DistributedHttpSessionManager.java,v 1.14 2002/04/16 20:29:57
jules_gosnell Exp $
* @author [EMAIL PROTECTED]
*/
//
@@ -209,7 +213,7 @@
public class DistributedHttpSessionManager
implements org.mortbay.jetty.servlet.SessionManager
{
- static AbstractTimeOutManager_scavenger =new
NaiveTimeOutManager(5*1000, new MyTimeOutHelper());
+ static AbstractTimeOutManager_scavenger =new
NaiveTimeOutManager(5*1000, new DistributedHttpSessionTimer());
final AbstractStore _store;
final SnapshotStrategy _snapshotStrategy;
final Logger _log;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
Why runs.sh... this is what was concerned about. Can you please explain this. --jason Quoting Francisco Reverbel <[EMAIL PROTECTED]>: > Yes, the iiop stuff is now generated by a default build. > > I have changed a couple of files (jboss-services.xml and run.sh) > in order to run it. Please see the patchfile attached. > > Should I commit these changes? > > Cheers, > > Francisco > > PS: David Jencks is getting a very strange error from rmic. > Are you also getting this error? > > On Mon, 15 Apr 2002, Jason Dillon wrote: > > > I setup the build system to include jboss.net & iiop in the default > > builds. Please look at the configuration that is generated and make > > sure that iiop stuff will work with a default build. > > > > Note, this is on HEAD. > > > > --jason > > > > > > Francisco Reverbel wrote: > > > > >Will it include the iiop stuff? Jason and I were talking about > > >making it part of the default build. > > > > > >User feedback would be a good thing for me at this point. > > > > > >Best, > > > > > >Francisco > > > > > >On Sun, 14 Apr 2002, Scott M Stark wrote: > > > > > >>I'm creating the 3.0 branch for the RC1 release at midnight > > >>(GMT-0700). Do not commit any changes to main after > > >>22:00 -0700 until the branch is announced to be complete. > > >> > > >> > > >>Scott Stark > > >>Chief Technology Officer > > >>JBoss Group, LLC > > >> > > >> > > >> > > >> > > >>___ > > >>Jboss-development mailing list > > >>[EMAIL PROTECTED] > > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > >> > > > > > > > > > > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Yes, please do this. --jason Quoting Bill Burke <[EMAIL PROTECTED]>: > Can you pull IIOP out of jboss-services.xml and put in in a separate > deployable service xml file like cluster-service.xml, etc..? I think this > would be better. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Francisco Reverbel > > Sent: Tuesday, April 16, 2002 12:47 PM > > To: Jason Dillon > > Cc: Scott M Stark; [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 > > > > > > Yes, the iiop stuff is now generated by a default build. > > > > I have changed a couple of files (jboss-services.xml and run.sh) > > in order to run it. Please see the patchfile attached. > > > > Should I commit these changes? > > > > Cheers, > > > > Francisco > > > > PS: David Jencks is getting a very strange error from rmic. > > Are you also getting this error? > > > > On Mon, 15 Apr 2002, Jason Dillon wrote: > > > > > I setup the build system to include jboss.net & iiop in the default > > > builds. Please look at the configuration that is generated and make > > > sure that iiop stuff will work with a default build. > > > > > > Note, this is on HEAD. > > > > > > --jason > > > > > > > > > Francisco Reverbel wrote: > > > > > > >Will it include the iiop stuff? Jason and I were talking about > > > >making it part of the default build. > > > > > > > >User feedback would be a good thing for me at this point. > > > > > > > >Best, > > > > > > > >Francisco > > > > > > > >On Sun, 14 Apr 2002, Scott M Stark wrote: > > > > > > > >>I'm creating the 3.0 branch for the RC1 release at midnight > > > >>(GMT-0700). Do not commit any changes to main after > > > >>22:00 -0700 until the branch is announced to be complete. > > > >> > > > >> > > > >>Scott Stark > > > >>Chief Technology Officer > > > >>JBoss Group, LLC > > > >> > > > >> > > > >> > > > >> > > > >>___ > > > >>Jboss-development mailing list > > > >>[EMAIL PROTECTED] > > > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >> > > > > > > > > > > > > > > > > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Are we logging the exception enough!!!
yeah I have the same gripe :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, April 16, 2002 1:23 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Are we logging the exception enough!!! | | |The following exception is getting logged by the StatelessSessionContainer, |the EjbModule, and finally the MainDeployer 3 times, and this is |overkill in |my |book. If an exception is being thrown or rethrown I don't think it |should be |logged unless trace level logging is enabled. The MainDeployer could better |handle reporting the failure of a nested deployment so that redundant |logging |does not occur. | |13:00:07,937 WARN [EjbModule] you are using deprecated |JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory |13:00:07,953 ERROR [StatelessSessionContainer] Exception in |service lifecyle |operation: create |org.jboss.deployment.DeploymentException: There are no home interface |interceptors configured |at |org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactor |y.java:21 |6) |at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) |at |org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionCont |ainer.jav |a:175) |at org.jboss.ejb.Container.invoke(Container.java:790) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at |org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContr |oller.jav |a:867) |at $Proxy0.create(Unknown Source) |at |org.jboss.system.ServiceController.create(ServiceController.java:271) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy18.create(Unknown Source) |at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) |at |org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at |org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContr |oller.jav |a:867) |at $Proxy0.create(Unknown Source) |at |org.jboss.system.ServiceController.create(ServiceController.java:271) |at |org.jboss.system.ServiceController.create(ServiceController.java:211) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy5.create(Unknown Source) |at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) |at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) |at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy4.deploy(Unknown Source) |at |org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploym |entScanne |r.java:350) |at |org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URL |Deploymen |tScanner.java:530) |at |org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymen |tScanner. |java:410) |at |org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThrea |d.loop(Ab |stractDeploymentScanner.java:202) |at |org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThrea |d.run(Abs |tractDeploymentScanner.java:191) | |13:00:08,062 WARN [ServiceController] Ignoring request to destroy |non-existant |service: jboss.j2ee:service=EJB,jndiName=tomcat-test/Optimized |13:00:08,062 INFO [EjbModule] Remove JSR-77 EJB Module: |jboss.management.single:J2EEApplication=tomcat-test.ear,J2EEServer= |Single,j2 |eeType=EJBModule,name=tomca |t-test.jar |13:00:08,078 ERROR [EjbModule] Initialization failed |org.jboss.deployment.DeploymentException: There are no home interface |interceptors configured |at |org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactor |y.java:21 |6) |at org.jboss.pro
[JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the "Class-Path" entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/ejb ProxyFactory.java
User: starksm
Date: 02/04/16 13:18:21
Modified:src/main/org/jboss/proxy/ejb ProxyFactory.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
1.14 +93 -73jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java
Index: ProxyFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ProxyFactory.java 13 Mar 2002 03:24:23 - 1.13
+++ ProxyFactory.java 16 Apr 2002 20:18:21 - 1.14
@@ -26,24 +26,25 @@
import javax.naming.NameNotFoundException;
import javax.management.ObjectName;
+import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvoker;
import org.jboss.ejb.ContainerInvokerContainer;
+import org.jboss.ejb.FinderResults;
+import org.jboss.ejb.ListCacheKey;
import org.jboss.invocation.Invoker;
import org.jboss.invocation.InvocationContext;
-import org.jboss.proxy.Interceptor;
-import org.jboss.proxy.ClientContainer;
-import org.jboss.proxy.ejb.handle.HomeHandleImpl;
+import org.jboss.logging.Logger;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.SessionMetaData;
import org.jboss.naming.Util;
+import org.jboss.proxy.Interceptor;
+import org.jboss.proxy.ClientContainer;
+import org.jboss.proxy.ejb.handle.HomeHandleImpl;
import org.jboss.system.Registry;
-import org.jboss.ejb.FinderResults;
-import org.jboss.ejb.ListCacheKey;
-
-import org.jboss.logging.Logger;
+import org.jboss.util.NestedRuntimeException;
import org.w3c.dom.Element;
@@ -62,7 +63,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Scott Stark/a>
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*
* Revisions:
* 2001/12/30: billb
@@ -205,15 +206,19 @@
/** Load the client interceptor classes
*/
- protected void initInterceptorClasses()
+ protected void initInterceptorClasses() throws Exception
{
ConfigurationMetaData configMetaData =
container.getBeanMetaData().getContainerConfiguration();
Element homeInterceptorConf =
configMetaData.getClientInterceptorConf(HOME_INTERCEPTOR);
loadInterceptorClasses(homeInterceptorClasses, homeInterceptorConf);
+ if( homeInterceptorClasses.size() == 0 )
+ throw new DeploymentException("There are no home interface interceptors
configured");
Element beanInterceptorConf =
configMetaData.getClientInterceptorConf(BEAN_INTERCEPTOR);
loadInterceptorClasses(beanInterceptorClasses, beanInterceptorConf);
+ if( beanInterceptorClasses.size() == 0 )
+ throw new DeploymentException("There are no bean interface interceptors
configured");
Element listEntityInterceptorConf =
configMetaData.getClientInterceptorConf(LIST_ENTITY_INTERCEPTOR);
loadInterceptorClasses(listEntityInterceptorClasses,
listEntityInterceptorConf);
@@ -225,55 +230,44 @@
* @exception Exception if an error occurs
*/
protected void loadInterceptorClasses(ArrayList classes, Element interceptors)
+ throws Exception
{
- try
+ Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
"interceptor");
+ ClassLoader loader = container.getClassLoader();
+ Interceptor last = null;
+ while( interceptorElements != null && interceptorElements.hasNext() )
{
- Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
"interceptor");
- ClassLoader loader = container.getClassLoader();
- Interceptor last = null;
- while( interceptorElements != null && interceptorElements.hasNext() )
- {
-Element ielement = (Element) interceptorElements.next();
-String className = null;
-className = MetaData.getElementContent(ielement);
-Class clazz = loader.loadClass(className);
-classes.add(clazz);
- }
- }
- catch (Exception ex)
- {
- log.error("failed to load client interceptor chain", ex);
+ Element ielement = (Element) interceptorElements.next();
+ String className = null;
+ className = MetaData.getElementContent(ielement);
+ Class clazz = loader.loadClass(className);
+ classes.add(clazz);
}
}
+
/** The loadInterceptorChain create instances of interceptor
* classes previously loaded in loadInterceptorClasses
*
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/ejb ProxyFactory.java
User: starksm
Date: 02/04/16 13:17:13
Modified:src/main/org/jboss/proxy/ejb Tag: Branch_3_0
ProxyFactory.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
No revision
No revision
1.13.2.1 +93 -73jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java
Index: ProxyFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- ProxyFactory.java 13 Mar 2002 03:24:23 - 1.13
+++ ProxyFactory.java 16 Apr 2002 20:17:13 - 1.13.2.1
@@ -26,24 +26,25 @@
import javax.naming.NameNotFoundException;
import javax.management.ObjectName;
+import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvoker;
import org.jboss.ejb.ContainerInvokerContainer;
+import org.jboss.ejb.FinderResults;
+import org.jboss.ejb.ListCacheKey;
import org.jboss.invocation.Invoker;
import org.jboss.invocation.InvocationContext;
-import org.jboss.proxy.Interceptor;
-import org.jboss.proxy.ClientContainer;
-import org.jboss.proxy.ejb.handle.HomeHandleImpl;
+import org.jboss.logging.Logger;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.SessionMetaData;
import org.jboss.naming.Util;
+import org.jboss.proxy.Interceptor;
+import org.jboss.proxy.ClientContainer;
+import org.jboss.proxy.ejb.handle.HomeHandleImpl;
import org.jboss.system.Registry;
-import org.jboss.ejb.FinderResults;
-import org.jboss.ejb.ListCacheKey;
-
-import org.jboss.logging.Logger;
+import org.jboss.util.NestedRuntimeException;
import org.w3c.dom.Element;
@@ -62,7 +63,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Scott Stark/a>
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.13.2.1 $
*
* Revisions:
* 2001/12/30: billb
@@ -205,15 +206,19 @@
/** Load the client interceptor classes
*/
- protected void initInterceptorClasses()
+ protected void initInterceptorClasses() throws Exception
{
ConfigurationMetaData configMetaData =
container.getBeanMetaData().getContainerConfiguration();
Element homeInterceptorConf =
configMetaData.getClientInterceptorConf(HOME_INTERCEPTOR);
loadInterceptorClasses(homeInterceptorClasses, homeInterceptorConf);
+ if( homeInterceptorClasses.size() == 0 )
+ throw new DeploymentException("There are no home interface interceptors
configured");
Element beanInterceptorConf =
configMetaData.getClientInterceptorConf(BEAN_INTERCEPTOR);
loadInterceptorClasses(beanInterceptorClasses, beanInterceptorConf);
+ if( beanInterceptorClasses.size() == 0 )
+ throw new DeploymentException("There are no bean interface interceptors
configured");
Element listEntityInterceptorConf =
configMetaData.getClientInterceptorConf(LIST_ENTITY_INTERCEPTOR);
loadInterceptorClasses(listEntityInterceptorClasses,
listEntityInterceptorConf);
@@ -225,55 +230,44 @@
* @exception Exception if an error occurs
*/
protected void loadInterceptorClasses(ArrayList classes, Element interceptors)
+ throws Exception
{
- try
+ Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
"interceptor");
+ ClassLoader loader = container.getClassLoader();
+ Interceptor last = null;
+ while( interceptorElements != null && interceptorElements.hasNext() )
{
- Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
"interceptor");
- ClassLoader loader = container.getClassLoader();
- Interceptor last = null;
- while( interceptorElements != null && interceptorElements.hasNext() )
- {
-Element ielement = (Element) interceptorElements.next();
-String className = null;
-className = MetaData.getElementContent(ielement);
-Class clazz = loader.loadClass(className);
-classes.add(clazz);
- }
- }
- catch (Exception ex)
- {
- log.error("failed to load client interceptor chain", ex);
+ Element ielement = (Element) interceptorElements.next();
+ String className = null;
+ className = MetaData.getElementContent(ielement);
+ Class clazz = loader.loadClass(className);
+ classes.add(clazz);
}
}
+
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy ClientContainer.java
User: starksm
Date: 02/04/16 13:17:12
Modified:src/main/org/jboss/proxy Tag: Branch_3_0
ClientContainer.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
No revision
No revision
1.1.2.1 +4 -24 jboss/src/main/org/jboss/proxy/ClientContainer.java
Index: ClientContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ClientContainer.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- ClientContainer.java 7 Mar 2002 18:20:49 - 1.1
+++ ClientContainer.java 16 Apr 2002 20:17:10 - 1.1.2.1
@@ -20,29 +20,9 @@
import org.jboss.invocation.Invocation;
import org.jboss.invocation.InvocationContext;
-/*
-import javax.transaction.TransactionManager;
-import java.security.Principal;
-import javax.transaction.Transaction;
-import javax.transaction.SystemException;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-import javax.ejb.EJBObject;
-import javax.ejb.EJBHome;
-import java.rmi.RemoteException;
-
-import org.jboss.proxy.ejb.ReadAheadBuffer;
-import org.jboss.proxy.ejb.ListEntityProxy;
-import org.jboss.invocation.Invocation;
-import org.jboss.invocation.Invoker;
-import org.jboss.tm.TransactionPropagationContextFactory;
-import org.jboss.security.SecurityAssociation;
-*/
-
/**
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.1.2.1 $
*
* 2001/11/19: marcf
*
@@ -50,7 +30,7 @@
*
*/
public class ClientContainer
-implements Externalizable, InvocationHandler
+ implements Externalizable, InvocationHandler
{
// the "static" information that gets attached to every invocation
@@ -104,7 +84,7 @@
}
public void writeExternal(final ObjectOutput out)
- throws IOException
+ throws IOException
{
out.writeObject(next);
out.writeObject(context);
@@ -119,7 +99,7 @@
* @throws ClassNotFoundException
*/
public void readExternal(final ObjectInput in)
- throws IOException, ClassNotFoundException
+ throws IOException, ClassNotFoundException
{
next = (Interceptor) in.readObject();
context = (InvocationContext) in.readObject();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
