[JBoss-dev] bug???
Hi, I'm using JBoss-2.2.1 with Tomcat-3.2.1 integrated. doesn't work in JSP as expected, instead org.apache.jasper.compiler.ParseException was thrown by JBoss. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml run_tests.xml
User: starksm Date: 01/05/10 22:11:28 Modified:src/build build.xml run_tests.xml Log: Update the naming tests to use the new abbreviated resource-ref mapping syntax in addition to the resource-ref/resource-managers syntax Revision ChangesPath 1.30 +1 -0 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- build.xml 2001/05/08 23:00:23 1.29 +++ build.xml 2001/05/11 05:11:28 1.30 @@ -43,6 +43,7 @@ + 1.7 +7 -1 jbosstest/src/build/run_tests.xml Index: run_tests.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/run_tests.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- run_tests.xml 2001/05/05 20:54:05 1.6 +++ run_tests.xml 2001/05/11 05:11:28 1.7 @@ -2,7 +2,7 @@ @@ -137,6 +137,10 @@ complete successfully. --> + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/META-INF ejb-jar.xml jboss.xml
User: starksm Date: 01/05/10 22:11:28 Modified:src/resources/naming/META-INF ejb-jar.xml jboss.xml Log: Update the naming tests to use the new abbreviated resource-ref mapping syntax in addition to the resource-ref/resource-managers syntax Revision ChangesPath 1.3 +12 -1 jbosstest/src/resources/naming/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/ejb-jar.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-jar.xml 2001/04/26 07:56:21 1.2 +++ ejb-jar.xml 2001/05/11 05:11:28 1.3 @@ -96,7 +96,18 @@ Container - + +The JBoss Web Site HomePage +url/JBossHomePage +java.net.URL +Container + + +The SourceForge HomePage +url/SourceforgeHomePage +java.net.URL +Container + 1.3 +16 -6 jbosstest/src/resources/naming/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/jboss.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss.xml 2001/04/26 07:56:21 1.2 +++ jboss.xml 2001/05/11 05:11:28 1.3 @@ -15,17 +15,27 @@ jnp://banshee:1099/ENCTests/ejbs/RemoteENCBean -DefaultDS jdbc/DefaultDS +DefaultDS -DefaultMail mail/DefaultMail +DefaultMail + -QueFactory jms/QueFactory +QueueConnectionFactory + + +url/JBossHomePage +http://www.jboss.org/ + + +url/SourceforgeHomePage +SourceforgeHomePage + ENCBean1 @@ -42,9 +52,9 @@ DefaultMail java:/Mail - -QueFactory -QueueConnectionFactory + +SourceforgeHomePage +http://sourceforge.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/ejb TestENCBean.java
User: starksm
Date: 01/05/10 22:11:28
Modified:src/main/org/jboss/test/naming/ejb TestENCBean.java
Log:
Update the naming tests to use the new abbreviated resource-ref mapping
syntax in addition to the resource-ref/resource-managers syntax
Revision ChangesPath
1.3 +23 -5 jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java
Index: TestENCBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestENCBean.java 2001/04/26 07:56:59 1.2
+++ TestENCBean.java 2001/05/11 05:11:28 1.3
@@ -7,13 +7,12 @@
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
-import javax.sql.DataSource;
/** A bean that does nothing but access resources from the ENC
to test ENC usage.
@author [EMAIL PROTECTED]
-@version $Revision: 1.2 $
+@version $Revision: 1.3 $
*/
public class TestENCBean implements SessionBean
{
@@ -49,6 +48,7 @@
testJdbcDataSource(initCtx, myEnv);
testMail(initCtx, myEnv);
testJMS(initCtx, myEnv);
+testURL(initCtx, myEnv);
}
catch(NamingException e)
{
@@ -78,6 +78,8 @@
{
// EJB References
Object ejb = myEnv.lookup("ejb/bean0");
+if( (ejb instanceof javax.ejb.EJBHome) == false )
+throw new NamingException("ejb/bean0 is not a javax.ejb.EJBHome");
System.out.println("ejb/bean0 = "+ejb);
ejb = initCtx.lookup("java:comp/env/ejb/bean1");
System.out.println("ejb/bean1 = "+ejb);
@@ -88,20 +90,36 @@
private void testJdbcDataSource(Context initCtx, Context myEnv) throws
NamingException
{
// JDBC DataSource
-DataSource ds = (DataSource) myEnv.lookup("jdbc/DefaultDS");
-System.out.println("jdbc/DefaultDS = "+ds);
+Object obj = myEnv.lookup("jdbc/DefaultDS");
+if( (obj instanceof javax.sql.DataSource) == false )
+throw new NamingException("jdbc/DefaultDS is not a
javax.sql.DataSource");
+System.out.println("jdbc/DefaultDS = "+obj);
}
private void testMail(Context initCtx, Context myEnv) throws NamingException
{
// JavaMail Session
Object obj = myEnv.lookup("mail/DefaultMail");
+if( (obj instanceof javax.mail.Session) == false )
+throw new NamingException("mail/DefaultMail is not a
javax.mail.Session");
System.out.println("mail/DefaultMail = "+obj);
}
private void testJMS(Context initCtx, Context myEnv) throws NamingException
{
// JavaMail Session
Object obj = myEnv.lookup("jms/QueFactory");
+if( (obj instanceof javax.jms.QueueConnectionFactory) == false )
+throw new NamingException("mail/DefaultMail is not a
javax.jms.QueueConnectionFactory");
System.out.println("jms/QueFactory = "+obj);
}
-
+private void testURL(Context initCtx, Context myEnv) throws NamingException
+{
+// JavaMail Session
+Object obj = myEnv.lookup("url/JBossHomePage");
+if( (obj instanceof java.net.URL) == false )
+throw new NamingException("url/JBossHomePage is not a java.net.URL");
+System.out.println("url/SourceforgeHomePage = "+obj);
+obj = myEnv.lookup("url/SourceforgeHomePage");
+System.out.println("url/SourceforgeHomePage = "+obj);
+}
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/lib mail.jar
User: starksm Date: 01/05/10 22:11:28 Added: src/lib mail.jar Log: Update the naming tests to use the new abbreviated resource-ref mapping syntax in addition to the resource-ref/resource-managers syntax Revision ChangesPath 1.1 jbosstest/src/lib/mail.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-423225 ] Simplified resource-ref mapping
Change Notes item #423225, was updated on 2001-05-10 22:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=423225&group_id=22866 Category: None Group: v2.4 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Simplified resource-ref mapping Initial Comment: A change in the jboss.xml dtd was made to allow the specification of a resource-ref jndi name or URL in the jboss.xml resource-ref element for cases where the extra indirection of a resource-managers specification isn't worth the trouble. For example, this is now a valid specification for a jdbc DataSource: ... jdbc/MyDS javax.sql.DataSource Container can be mapped to the deployed JNDI resource using this jboss.xml descriptor: ... jdbc/MyDS java:/MyDS where previously this would have required the following jboss.xml descriptor: ... jdbc/MyDS MyDS MyDS java:/MyDS -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=423225&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata BeanMetaData.java ResourceRefMetaData.java
User: starksm
Date: 01/05/10 21:52:02
Modified:src/main/org/jboss/metadata BeanMetaData.java
ResourceRefMetaData.java
Log:
Allow the specification of a resource-ref jndi name or URL in the
jboss.xml resource-ref element for cases where the extra indirection
of a resource-managers specification isn't worth the trouble
Revision ChangesPath
1.16 +2 -4 jboss/src/main/org/jboss/metadata/BeanMetaData.java
Index: BeanMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/BeanMetaData.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- BeanMetaData.java 2001/02/27 16:37:53 1.15
+++ BeanMetaData.java 2001/05/11 04:52:02 1.16
@@ -25,7 +25,7 @@
* @see
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
- * @version $Revision: 1.15 $
+ * @version $Revision: 1.16 $
*/
public abstract class BeanMetaData extends MetaData {
// Constants -
@@ -251,14 +251,12 @@
while (iterator.hasNext()) {
Element resourceRef = (Element)iterator.next();
String resRefName =
getElementContent(getUniqueChild(resourceRef, "res-ref-name"));
- String resourceName =
getElementContent(getUniqueChild(resourceRef, "resource-name"));
ResourceRefMetaData resourceRefMetaData =
(ResourceRefMetaData)resourceReferences.get(resRefName);
if (resourceRefMetaData == null) {
throw new DeploymentException("resource-ref " + resRefName + "
found in jboss.xml but not in ejb-jar.xml");
}
-
- resourceRefMetaData.setResourceName(resourceName);
+resourceRefMetaData.importJbossXml(resourceRef);
}
// set the external ejb-references (optional)
1.4 +33 -9 jboss/src/main/org/jboss/metadata/ResourceRefMetaData.java
Index: ResourceRefMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ResourceRefMetaData.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ResourceRefMetaData.java 2000/12/07 15:45:01 1.3
+++ ResourceRefMetaData.java 2001/05/11 04:52:02 1.4
@@ -15,19 +15,29 @@
*
* @see
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class ResourceRefMetaData extends MetaData {
// Constants -
// Attributes
- private String refName; // the name used in the bean code (from
ejb-jar.xml)
- private String name; // the name of the resource used by jboss
- // the jndi name will be found in the ApplicationMetaData where resources are
declared
-
+/** The ejb-jar.xml/../resource-ref/res-ref-name element used by the bean code
*/
+ private String refName;
+/** The jboss.xml/../resource-ref/resource-name value that maps to a
resource-manager */
+ private String name;
+/** The jndi name of the deployed resource, or the URL in the case of
+ a java.net.URL resource type. This comes from either the:
+ jboss.xml/../resource-ref/jndi-name element value or the
+ jboss.xml/../resource-ref/res-url element value or the
+ jboss.xml/../resource-manager/res-jndi-name element value
+ jboss.xml/../resource-manager/res-url element value
+ */
+ private String jndiName;
+ /** The ejb-jar.xml/../resource-ref/res-type java classname of the resource */
private String type;
+/** The ejb-jar.xml/../resource-ref/res-auth value */
private boolean containerAuth;
-
+
// Static
// Constructors --
@@ -49,7 +59,7 @@
public void setResourceName(String resName) {
name = resName;
}
-
+public String getJndiName() { return jndiName; }
public String getType() { return type; }
public boolean isContainerAuth() { return containerAuth; }
@@ -71,9 +81,23 @@
}
public void importJbossXml(Element element) throws DeploymentException {
- name = getElementContent(getUniqueChild(element, "resource-name"));
+// Look for the resource-ref/resource-name element
+Element child = getOptionalChild(element, "resource-name");
+
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: starksm
Date: 01/05/10 21:52:02
Modified:src/main/org/jboss/ejb Container.java
Log:
Allow the specification of a resource-ref jndi name or URL in the
jboss.xml resource-ref element for cases where the extra indirection
of a resource-managers specification isn't worth the trouble
Revision ChangesPath
1.38 +6 -7 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.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- Container.java2001/02/27 16:48:07 1.37
+++ Container.java2001/05/11 04:52:02 1.38
@@ -67,7 +67,7 @@
* @see ContainerFactory
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author Marc Fleury
- * @version $Revision: 1.37 $
+ * @version $Revision: 1.38 $
*/
public abstract class Container
{
@@ -467,6 +467,10 @@
String resourceName = ref.getResourceName();
String finalName = application.getResourceByName(resourceName);
+ /* If there was no resource-manager specified then an immeadiate
+jndi-name or res-url name should have been given */
+ if (finalName == null)
+ finalName = ref.getJndiName();
if (finalName == null)
{
@@ -497,12 +501,7 @@
}
}
- if (ref.getType().equals("javax.sql.DataSource"))
- {
- // Datasource bindings
- bind(ctx, ref.getRefName(), new LinkRef(finalName));
- }
- else if (ref.getType().equals("java.net.URL"))
+ if (ref.getType().equals("java.net.URL"))
{
// URL bindings
try
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default log4j.properties
User: starksm Date: 01/05/10 19:51:42 Modified:src/etc/conf/default log4j.properties Log: Update the console appender class name Revision ChangesPath 1.7 +1 -1 jboss/src/etc/conf/default/log4j.properties Index: log4j.properties === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/log4j.properties,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- log4j.properties 2001/05/04 06:09:21 1.6 +++ log4j.properties 2001/05/11 02:51:42 1.7 @@ -15,7 +15,7 @@ #log4j.category.DefaultDS=FATAL ### The console appender -log4j.appender.Console=org.jboss.logging.ConsoleAppender +log4j.appender.Console=org.jboss.logging.log4j.ConsoleAppender log4j.appender.Console.Threshold=INFO log4j.appender.Console.layout=org.apache.log4j.PatternLayout log4j.appender.Console.layout.ConversionPattern=[%c] %m%n ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging/log4j CategoryStream.java ConsoleAppender.java
User: starksm
Date: 01/05/10 19:50:29
Added: src/main/org/jboss/logging/log4j CategoryStream.java
ConsoleAppender.java
Log:
Create a log4j specific subpackage for custom log4j classes.
Revision ChangesPath
1.1 jboss/src/main/org/jboss/logging/log4j/CategoryStream.java
Index: CategoryStream.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.logging.log4j;
import java.io.PrintStream;
import org.apache.log4j.Category;
import org.apache.log4j.Priority;
/** A subclass of PrintStream that redirects its output to a log4j Category.
This class is used to map PrintStream/PrintWriter oriented logging onto
the log4j Categories. Examples include capturing System.out/System.err writes.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class CategoryStream extends PrintStream
{
private Category category;
private Priority priority;
/** Redirect logging to the indicated category using Priority.INFO
*/
public CategoryStream(Category category)
{
this(category, Priority.INFO, System.out);
}
/** Redirect logging to the indicated category using the given
priority. The ps is simply passed to super but is not used.
*/
public CategoryStream(Category category, Priority priority, PrintStream ps)
{
super(ps);
this.category = category;
this.priority = priority;
}
public void println(String msg)
{
category.log(priority, msg);
}
public void println(Object msg)
{
category.log(priority, msg);
}
public void write(byte[] b, int off, int len)
{
// Remove the end of line chars
while( (b[len-1] == '\n' || b[len-1] == '\r') && len > off )
len --;
String msg = new String(b, off, len);
category.log(priority, msg);
}
}
1.1 jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java
Index: ConsoleAppender.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.logging.log4j;
import java.io.PrintStream;
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Category;
import org.apache.log4j.Priority;
import org.apache.log4j.spi.LoggingEvent;
/** A log4j Appender implementation that writes to the System.out and
System.err console streams. It also installs PrintStreams for System.out
and System.err to route logging through those objects to the log4j
system via a category named Default.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class ConsoleAppender extends AppenderSkeleton
{
private Category category;
private PrintStream out;
private PrintStream err;
/** Creates new ConsoleAppender */
public ConsoleAppender()
{
out = System.out;
err = System.err;
}
public void activateOptions()
{
super.activateOptions();
category = Category.getInstance("Default");
System.setOut(new CategoryStream(category, Priority.INFO, out));
System.setErr(new CategoryStream(category, Priority.ERROR, err));
}
public boolean requiresLayout()
{
return true;
}
public void close()
{
if( out != null )
System.setOut(out);
out = null;
if( err != null )
System.setErr(err);
err = null;
}
protected void append(LoggingEvent event)
{
String msg = this.layout.format(event);
if( event.priority == Priority.ERROR )
out.print(msg);
else
err.print(msg);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging ConsoleAppender.java
User: starksm Date: 01/05/10 19:50:29 Removed: src/main/org/jboss/logging ConsoleAppender.java Log: Create a log4j specific subpackage for custom log4j classes. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging/log4j - New directory
User: starksm Date: 01/05/10 19:43:51 jboss/src/main/org/jboss/logging/log4j - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JBoss daily test results SUMMARY Number of tests run: 67 Successful tests: 61 Errors:2 Failures: 4 DETAILS OF ERRORS Suite: org.jboss.test.cts.test.AllJUnitTests Test:testRemoveSessionObject Type:failure Exception: junit.framework.AssertionFailedError Message: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) Stack Trace: junit.framework.AssertionFailedError: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:188) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testProbeBeanContext Type:failure Exception: junit.framework.AssertionFailedError Message: Caught an unknown exception in testProbeBeanContex Stack Trace: junit.framework.AssertionFailedError: Caught an unknown exception in testProbeBeanContex at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:467) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testEjbRemove Type:failure Exception: junit.framework.AssertionFailedError Message: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. Stack Trace: junit.framework.AssertionFailedError: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.BmpTest.testEjbRemove(BmpTest.java:224) at java.lang.reflect.Method
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/client ConnectorFactoryImpl.java ConnectorFactoryService.java
User: schaefera
Date: 01/05/10 15:01:17
Modified:src/main/org/jboss/jmx/client ConnectorFactoryImpl.java
ConnectorFactoryService.java
Log:
Some minor fixes.
Revision ChangesPath
1.7 +0 -6 jboss/src/main/org/jboss/jmx/client/ConnectorFactoryImpl.java
Index: ConnectorFactoryImpl.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/client/ConnectorFactoryImpl.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ConnectorFactoryImpl.java 2001/05/04 21:18:05 1.6
+++ ConnectorFactoryImpl.java 2001/05/10 22:01:17 1.7
@@ -71,7 +71,6 @@
NamingEnumeration enum = lNamingServer.list( "" );
while( enum.hasMore() ) {
NameClassPair lItem = ( NameClassPair ) enum.next();
-System.out.println( "Naming Server item: " + lItem );
ConnectorName lName = pTester.check( lItem.getName(), lItem.getClass()
);
if( lName != null ) {
lConnectors.add( lName );
@@ -111,7 +110,6 @@
e.printStackTrace();
}
}
- System.out.println( "ConnectorFactoryImpl.createConnection(), got connector:
" + lConnector );
return lConnector;
}
@@ -129,7 +127,6 @@
new ObjectName( "DefaultDomain:name=RMIConnectorTo" +
pConnector.getServer() ),
null
);
-System.out.println( "ConnectorFactoryImpl.removeConnection(), got
connectors: " + lConnectors );
if( !lConnectors.isEmpty() ) {
Iterator i = lConnectors.iterator();
while( i.hasNext() ) {
@@ -142,9 +139,6 @@
);
mServer.unregisterMBean(
lConnector.getObjectName()
- );
- System.out.println( "ConnectorFactoryImpl.removeConnection(), " +
- "unregister MBean: " + lConnector.getObjectName()
);
}
}
1.6 +1 -5 jboss/src/main/org/jboss/jmx/client/ConnectorFactoryService.java
Index: ConnectorFactoryService.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/client/ConnectorFactoryService.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ConnectorFactoryService.java 2001/05/04 21:18:06 1.5
+++ ConnectorFactoryService.java 2001/05/10 22:01:17 1.6
@@ -52,7 +52,6 @@
}
public Iterator getConnectors( Hashtable pProperties,
ConnectorFactoryImpl.IConnectorTester pTester ) {
- System.out.println( "ConnectorFactoryService.getConnectors(),
properties: " + pProperties );
return mFactory.getConnectors( pProperties, pTester );
}
@@ -86,10 +85,7 @@
// Protected -
protected void initService() throws Exception {
try {
- System.out.println( "ConnectorFactoryService.initService(), server: "
+ mServer );
- mFactory = new ConnectorFactoryImpl( mServer );
- System.out.println( "ConnectorFactoryService.initService(), server: "
+ mServer +
- ", factory: " + mFactory );
+ mFactory = new ConnectorFactoryImpl( mServer );
}
catch( Exception e ) {
e.printStackTrace();
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/test/jboss/jmx TestClient.java
User: schaefera
Date: 01/05/10 14:58:00
Modified:src/main/test/jboss/jmx TestClient.java
Log:
Using "Instance".getClass().getName() instead of writing down the classpath
and name as a string.
Revision ChangesPath
1.8 +9 -6 jboss/src/main/test/jboss/jmx/TestClient.java
Index: TestClient.java
===
RCS file: /cvsroot/jboss/jboss/src/main/test/jboss/jmx/TestClient.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestClient.java 2001/05/04 21:18:50 1.7
+++ TestClient.java 2001/05/10 21:58:00 1.8
@@ -6,6 +6,7 @@
package test.jboss.jmx;
import java.util.Collection;
+import java.util.Hashtable;
import java.util.Iterator;
import java.util.Vector;
@@ -96,16 +97,18 @@
catch( Exception e ) {
e.printStackTrace();
}
+ Hashtable lProperties = lContext.getEnvironment();
+ ConnectorFactoryImpl.JBossConnectorTester lTester = new
ConnectorFactoryImpl.JBossConnectorTester();
Iterator lConnectors = (Iterator) lLocalServer.invoke(
lFactoryInstance.getObjectName(),
"getConnectors",
new Object[] {
- lContext.getEnvironment(),
- new ConnectorFactoryImpl.JBossConnectorTester()
+ lProperties,
+ lTester
},
new String[] {
- "java.util.Hashtable",
- "org.jboss.jmx.client.ConnectorFactoryImpl$IConnectorTester"
+ lProperties.getClass().getName(),
+ lTester.getClass().getName()
}
);
int lCount = 0;
@@ -148,7 +151,7 @@
lConnectorName
},
new String[] {
-
"org.jboss.jmx.client.ConnectorFactoryImpl$ConnectorName"
+ lConnectorName.getClass().getName()
}
);
getUserInput(
@@ -183,7 +186,7 @@
lConnectorName
},
new String[] {
-
"org.jboss.jmx.client.ConnectorFactoryImpl$ConnectorName"
+ lConnectorName.getClass().getName()
}
);
System.err.println("Shutting done");
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cts/test StatefulSessionTest.java
User: kimptoc
Date: 01/05/10 14:34:00
Modified:src/main/org/jboss/test/cts/test StatefulSessionTest.java
Log:
add some more comments to the removeexception test
Revision ChangesPath
1.8 +14 -13
jbosstest/src/main/org/jboss/test/cts/test/StatefulSessionTest.java
Index: StatefulSessionTest.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cts/test/StatefulSessionTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StatefulSessionTest.java 2001/04/29 08:04:59 1.7
+++ StatefulSessionTest.java 2001/05/10 21:34:00 1.8
@@ -17,8 +17,8 @@
/**
*
* @see
- * @author $Author: sparre $
- * @version $Revision: 1.7 $
+ * @author $Author: kimptoc $
+ * @version $Revision: 1.8 $
*/
public class StatefulSessionTest
@@ -95,7 +95,7 @@
"**");
System.out.println(" testEJBHomeInterface()");
- // Create a new session object
+ // Create a new session object
Context ctx = new InitialContext();
StatefulSessionHome home=
( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
@@ -165,7 +165,7 @@
System.out.println("Obtain home interface");
- // Create a new session object
+ // Create a new session object
Context ctx = new InitialContext(props);
StatefulSessionHome home =
( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
@@ -174,20 +174,21 @@
System.out.println("OK");
System.out.println("Call remove using a primary key");
home.remove(new AccountPK("pk"));
-
+
}
catch (javax.ejb.RemoveException rmEx)
{
- System.out.println("OK, got a remove exception!" );
+ System.out.println("OK, got a remove exception!" );
// Expected behavior
return;
}
catch (Exception ex)
{
- fail("[EJB 1.1, p42] Expected 'RemoveException', detail:" + ex.toString());
+ ex.printStackTrace();
+ fail("[EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when
remove-ing a session object, detail:" + ex.toString());
}
- fail("Expected 'RemoveException', got NO exception");
+ fail("[EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when
remove-ing a session object, got NO exception");
System.out.println(
"**");
}
@@ -219,7 +220,7 @@
System.out.println("Obtain home interface");
- // Create a new session object
+ // Create a new session object
Context ctx = new InitialContext(props);
StatefulSessionHome home =
( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
@@ -288,7 +289,7 @@
System.out.println("Obtain home interface");
- // Create a new session object
+ // Create a new session object
Context ctx = new InitialContext(props);
StatefulSessionHome home =
( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
@@ -416,7 +417,7 @@
{
System.out.println("Obtain home interface");
-// Create a new session object
+// Create a new session object
Context ctx = new InitialContext(props);
Object ref =
ctx.lookup("ejbcts/StatefulSessionBean");
@@ -492,7 +493,7 @@
System.out.println("Obtain home interface");
- // Create a new session object
+ // Create a new session object
Context ctx = new InitialContext(props);
StatefulSessionHome home =
( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
@@ -543,7 +544,7 @@
{
System.out.println("Obtain home interface");
-// Create a new session object
+// Create a new session object
Context ctx = new InitialContext(props);
Object ref =
ctx.lookup("ejbcts/StatefulSessionBean");
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss daily test results
Hi, > > > Suite: org.jboss.test.cts.test.AllJUnitTests > Test:testRemoveSessionObject > Type:failure > Exception: junit.framework.AssertionFailedError > Message: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: /home/lubega/jbossro/jboss/dist/db/sessions/StatefulSessionBean/org.jboss.te [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: /home/lubega/jbossro/jboss/dist/db/sessions/StatefulSessionBean/org.jboss.te [EMAIL PROTECTED] (No such file or directory) > Stack Trace: > junit.framework.AssertionFailedError: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: > javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: > java.io.FileNotFoundException: /home/lubega/jbossro/jboss/dist/db/sessions/StatefulSessionBean/org.jboss.te [EMAIL PROTECTED] (No such file or directory); nested exception is: > java.rmi.NoSuchObjectException: Could not activate; nested exception is: > java.io.FileNotFoundException: /home/lubega/jbossro/jboss/dist/db/sessions/StatefulSessionBean/org.jboss.te [EMAIL PROTECTED] (No such file or directory) > at junit.framework.Assert.fail(Assert.java:143) > at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(Stateful SessionTest.java:187) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:155) > at junit.framework.TestCase.runBare(TestCase.java:129) > at junit.framework.TestResult$1.protect(TestResult.java:100) > at junit.framework.TestResult.runProtected(TestResult.java:117) > at junit.framework.TestResult.run(TestResult.java:103) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.run(TestSuite.java:144) > at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:202) > at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestR unner.java:326) > This test is checking that calling remove on a session object raises a RemoveException. It looks as if the actual exception being raised is that the client/server interaction is having trouble passing the primary key object across. ...but I'd have thought the client/EJBObject should be able to answer this method call with the exception immediately - or does it not know that it is a session-type bean? Looking at HomeProxy/GenericProxy, it seems like it does not know... and it seems the you cannot tell from the client Home interface as it is the same for entity and session beans... Then on the server it tries to instantiate the object before it does the invocation - and that gives the above error. So - what do we do - add a remove method call specific check in the server handling of session invocations? - remove the test? - adjust the test to accept any exception as a pass? Regards, Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Main.java, let's clean it up
> 1- we keep the jboss.conf with just the CS/XMLet start
This would allow users to replace these with their own versions? How many
users are interested in doing that? If they are they could extend from
Main, or write there own to add functionality.
> 2- or we force loading the CS from the main (always) as the front end for
> the XMLet mechanism.
This seems a like a good start to simplify the configuration of the system.
The only problem that I can see is that logging will probably not be enabled
before the CS, since users will probably want to have control over that.
> BTW, XMLet is our own JBoss extension of the default MLet mechanism,
Does XMLet provide the same functionality as MLet but is XML compliant, or
is it completely different? I remember some talk about this before, but I
never got the gist of it.
Any ways I am in favor of removing jboss.conf, or rather having on primary
file for controlling the configuration of the server. If we are still going
to use the conf/jcml style then we definitely need an XML compliant conf
parser (which is what I think XMLet does... but I am not sure).
Along the lines of loading from a URL, does this also include classes?
Such that a server install would only required the bare minimum to connect
to a server for configuration and support class/resource downloads? If that
is true, is there going to be any caching of downloaded files (for large
.jar files and such)?
I was also wondering of there might be plans to enrich the jcml dtd to
include such things as property setting, bare mbean loading (not as a
service) and perhaps the ability to use value substitution (like ant does
with ${property.name}).
Just some thoughts. I am very interested in the configuration mechanism, so
if I can help out in any way please let me know.
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar
User: starksm Date: 01/05/10 13:27:47 Modified:src/lib jboss-jaas.jar jbosssx.jar Log: Integrate latest JBossSX update Revision ChangesPath 1.7 +6 -6 jboss/src/lib/jboss-jaas.jar <> 1.7 +17 -14jboss/src/lib/jbosssx.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Feature Requests-423134 ] Complain if ejb-jar in classpath
On Thu, May 10, 2001 at 03:51:55PM -0400, marc fleury wrote:
> you mean the ejb-jar.xml file in the classpath?
Yeah, what he said.
> yes I have seen this a lot in the excercise...
>
> the init of the Deployer (JMX) init should look for the ejb-jar.xml
>
> getClass().getClassLoader.loadResource("ejb-jar.xml");
>
> if everything OK bark and bark and bark and make loud noises
Exactly what I meant, yes.
> a more complex way of doing this is to make sure that the ejb-jar.xml comes
> from our ClassLoader but that would require an extension of the current
> URLCl used... since I want to do that for complex app support (probably for
> JBoss 3.0) then we would do that at the CL level. More complex but
> fool-proof, the barking won't work all the time
I think you're right that we need explicit handling for this in the
classloader. The delegation model really screws up with deployment
descriptors where we really want the opposite behaviour.
I made this a feature request because I probably won't get around to it
for a while, so if anyone wants to do this, go ahead. It's a nice simple
one for a beginner, even.
Toby.
> marc
>
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |[EMAIL PROTECTED]
> |Sent: Thursday, May 10, 2001 3:34 PM
> |To: [EMAIL PROTECTED]
> |Subject: [JBoss-dev] [ jboss-Feature Requests-423134 ] Complain if
> |ejb-jar in classpath
> |
> |
> |Feature Requests item #423134, was updated on 2001-05-10 12:33
> |You can respond by visiting:
> |http://sourceforge.net/tracker/?func=detail&atid=376688&aid=423134&;
> |group_id=22866
> |
> |Category: None
> |Group: None
> |Status: Open
> |Priority: 5
> |Submitted By: Toby Allsopp (tobyallsopp)
> |Assigned to: Nobody/Anonymous (nobody)
> |Summary: Complain if ejb-jar in classpath
> |
> |Initial Comment:
> |There are a number of people confused by problem caused
> |by having their ejb-jar file in the classpath when they
> |start JBoss.
> |
> |We should detect this when the server starts up
> |(perhaps when each deployer starts up it should check
> |for this) and tell them, in no uncertain terms, to fix
> |it.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BUILD PROBLEM - missing class org.jboss.security.plugins.NullSecurityManager
Yes, I need to update the jbosssx.jar. It will be in soon. - Original Message - From: "Chris Kimpton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 10, 2001 12:53 PM Subject: [JBoss-dev] BUILD PROBLEM - missing class org.jboss.security.plugins.NullSecurityManager > Hi, > > I get the following when building from the latest main branch CVS; > > [mkdir] Created dir: H:\cvslocal\jbossrw\jboss\build\classes > [javac] Compiling 430 source files to > H:\cvslocal\jbossrw\jboss\build\classes > [javac] > H:\cvslocal\jbossrw\jboss\src\main\org\jboss\web\AbstractWebContainer.java:2 > 4: Class org > .jboss.security.plugins.NullSecurityManager not found in import. > [javac] import org.jboss.security.plugins.NullSecurityManager; > [javac]^ > > > I guess a class is missing... > > Thanks, > Chris > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] BUILD PROBLEM - missing class org.jboss.security.plugins.NullSecurityManager
Hi, I get the following when building from the latest main branch CVS; [mkdir] Created dir: H:\cvslocal\jbossrw\jboss\build\classes [javac] Compiling 430 source files to H:\cvslocal\jbossrw\jboss\build\classes [javac] H:\cvslocal\jbossrw\jboss\src\main\org\jboss\web\AbstractWebContainer.java:2 4: Class org .jboss.security.plugins.NullSecurityManager not found in import. [javac] import org.jboss.security.plugins.NullSecurityManager; [javac]^ I guess a class is missing... Thanks, Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Feature Requests-423134 ] Complain if ejb-jar in classpath
you mean the ejb-jar.xml file in the classpath?
yes I have seen this a lot in the excercise...
the init of the Deployer (JMX) init should look for the ejb-jar.xml
getClass().getClassLoader.loadResource("ejb-jar.xml");
if everything OK bark and bark and bark and make loud noises
a more complex way of doing this is to make sure that the ejb-jar.xml comes
from our ClassLoader but that would require an extension of the current
URLCl used... since I want to do that for complex app support (probably for
JBoss 3.0) then we would do that at the CL level. More complex but
fool-proof, the barking won't work all the time
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Thursday, May 10, 2001 3:34 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] [ jboss-Feature Requests-423134 ] Complain if
|ejb-jar in classpath
|
|
|Feature Requests item #423134, was updated on 2001-05-10 12:33
|You can respond by visiting:
|http://sourceforge.net/tracker/?func=detail&atid=376688&aid=423134&;
|group_id=22866
|
|Category: None
|Group: None
|Status: Open
|Priority: 5
|Submitted By: Toby Allsopp (tobyallsopp)
|Assigned to: Nobody/Anonymous (nobody)
|Summary: Complain if ejb-jar in classpath
|
|Initial Comment:
|There are a number of people confused by problem caused
|by having their ejb-jar file in the classpath when they
|start JBoss.
|
|We should detect this when the server starts up
|(perhaps when each deployer starts up it should check
|for this) and tell them, in no uncertain terms, to fix
|it.
|
|--
|
|You can respond by visiting:
|http://sourceforge.net/tracker/?func=detail&atid=376688&aid=423134&;
|group_id=22866
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Main.java, let's clean it up
Hi Instead of loading CS by default from Main.java why not loading jboss.jcml by default and using a tag to figure out which CS to load. Example: I would advocate to kick "jboss.conf" out otherwise I think we wouldn't gain anything from this effort, do we? Andy > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 10, 2001 12:22 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Main.java, let's clean it up > > > The CS works from XML, the jcml files needs that already, > chicken and egg. > > what I was thinking about is > 1- we keep the jboss.conf with just the CS/XMLet start > 2- or we force loading the CS from the main (always) as the > front end for > the XMLet mechanism. > > BTW, XMLet is our own JBoss extension of the default MLet mechanism, > > marc > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of > |Schaefer, Andreas > |Sent: Thursday, May 10, 2001 12:51 PM > |To: '[EMAIL PROTECTED]' > |Subject: RE: [JBoss-dev] Main.java, let's clean it up > | > | > |How's about specifying the Configuration Service in the > |tag within the JCML file. > | > |Then the Main.java can start to read the JCML file and then > hand it over > |to the found Configuration Service. > | > |MAD Andy ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-423134 ] Complain if ejb-jar in classpath
Feature Requests item #423134, was updated on 2001-05-10 12:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=423134&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Toby Allsopp (tobyallsopp) Assigned to: Nobody/Anonymous (nobody) Summary: Complain if ejb-jar in classpath Initial Comment: There are a number of people confused by problem caused by having their ejb-jar file in the classpath when they start JBoss. We should detect this when the server starts up (perhaps when each deployer starts up it should check for this) and tell them, in no uncertain terms, to fix it. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=423134&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-422932 ] connector module for J2eeDeployer
On Thu, May 10, 2001 at 01:11:45AM -0700, [EMAIL PROTECTED] wrote: > Patches item #422932, was updated on 2001-05-10 01:11 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376687&aid=422932&group_id=22866 > > Category: JBossServer > Group: v2.3 (unstable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: Claudio Vesco (cazzius) > Assigned to: Nobody/Anonymous (nobody) > Summary: connector module for J2eeDeployer > > Initial Comment: > Hi! > > This is a patch file which permit the deployment of > connector modules in EAR applications > (application_1_3.dtd) You're a braver man than I. That J2eeDeployer code is horrible. Thanks for doing this. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Main.java, let's clean it up
The CS works from XML, the jcml files needs that already, chicken and egg. what I was thinking about is 1- we keep the jboss.conf with just the CS/XMLet start 2- or we force loading the CS from the main (always) as the front end for the XMLet mechanism. BTW, XMLet is our own JBoss extension of the default MLet mechanism, marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Schaefer, Andreas |Sent: Thursday, May 10, 2001 12:51 PM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] Main.java, let's clean it up | | |How's about specifying the Configuration Service in the |tag within the JCML file. | |Then the Main.java can start to read the JCML file and then hand it over |to the found Configuration Service. | |MAD Andy | |> -Original Message- |> From: marc fleury [mailto:[EMAIL PROTECTED]] |> Sent: Wednesday, May 09, 2001 5:30 PM |> To: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] Main.java, let's clean it up |> |> |> We could get rid of jboss.conf if we put all the logging and |> ClasspathExtension in jcml with a corresponding xml snippet. |> We would still |> need the conf or the main to set up the configuration service |> (at least). |> |> marc |> |> |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On |> Behalf Of Jason |> |Dillon |> |Sent: Wednesday, May 09, 2001 7:07 PM |> |To: [EMAIL PROTECTED] |> |Subject: RE: [JBoss-dev] Main.java, let's clean it up |> | |> | |> |Is this going to include merging jboss.conf and jboss.jcml into |> |one file (or |> |perhaps using a standard jboss.conf from a class resource for |> |boot-strapping) or will there still be two files? |> | |> |--jason |> | |> |On Wed, 9 May 2001, marc fleury wrote: |> |> |> |> |The setting of the security manager and server.policy file are |> |> |better done from |> |> |the command line as many security related events and |> debugging hooks are |> |> |done on startup of the vm. I don't think these should be |> set at all from |> |> |within the server. Setting the thread-local mode of the |> |SecurityAssociation |> |> |could be moved to an mbean. |> |> |> |> either command line or xml file. whichever you feel is more |> |"admin friendly" |> |> or both. |> |> |> |> I want to be done with the properties file asap. |> |> |> |> Let's simplify, the properties files is a big "ZIT" in our face |> |and I want |> |> to squeeze it "splatch" |> |> |> |> |> |> h feels good doesn't it? |> |> |> |> |If I comment out the call to |> DocumentBuilderFactory.newInstance() I am |> |> |still able to switch the xml parsers using the JAXP properties so |> |> |I don't see |> |> |that this call has any effect other than preloading the parser |> |classes. The |> |> |xml parser settings could be moved to an MLet. |> |> |> |> kaay voodoo refactoring if I move this does it die? |> |nope... ok |> |> then... :) |> |> |> |> we should configure the xml stuff in a mlet as well, although it |> |should be |> |> one of the first ones (we do the mbean based on xml :) |> |> |> |> marc |> |> |> |> | |> |> | |> |> | |> |> |___ |> |> |Jboss-development mailing list |> |> |[EMAIL PROTECTED] |> |> |http://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> |> |> |> |> |> ___ |> |> Jboss-development mailing list |> |> [EMAIL PROTECTED] |> |> http://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> | |> | |> |___ |> |Jboss-development mailing list |> |[EMAIL PROTECTED] |> |http://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> http://lists.sourceforge.net/lists/listinfo/jboss-development |> | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib tomcat-service.jar
User: starksm Date: 01/05/10 11:06:42 Modified:src/lib Tag: Branch_2_2 tomcat-service.jar Log: The tomcate-service.jar did not correspond to the JBoss_2_2_1 tagged code. Revision ChangesPath No revision No revision 1.9.2.1 +49 -37jboss/src/lib/tomcat-service.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/servlets DebugServlet.java SecureEJBServlet.java
User: starksm
Date: 01/05/10 10:43:47
Modified:src/main/org/jboss/test/web/servlets SecureEJBServlet.java
Added: src/main/org/jboss/test/web/servlets DebugServlet.java
Log:
Update the secured tests and add a DebugServlet
Revision ChangesPath
1.2 +22 -3
jbosstest/src/main/org/jboss/test/web/servlets/SecureEJBServlet.java
Index: SecureEJBServlet.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/servlets/SecureEJBServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SecureEJBServlet.java 2001/05/05 20:59:35 1.1
+++ SecureEJBServlet.java 2001/05/10 17:43:47 1.2
@@ -3,30 +3,49 @@
import java.io.IOException;
import java.io.PrintWriter;
import java.security.Principal;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.jboss.test.web.interfaces.StatelessSession;
+import org.jboss.test.web.interfaces.StatelessSessionHome;
+
/**
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class SecureEJBServlet extends HttpServlet
{
protected void processRequest(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException
{
+String echoMsg = null;
+try
+{
+InitialContext ctx = new InitialContext();
+StatelessSessionHome home = (StatelessSessionHome)
ctx.lookup("java:comp/env/ejb/SecuredEJB");
+StatelessSession bean = home.create();
+echoMsg = bean.echo("SecureEJBServlet");
+}
+catch(Exception e)
+{
+throw new ServletException("Failed to call SecuredEJB.echo", e);
+}
Principal user = request.getUserPrincipal();
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
out.println("ENCServlet");
out.println("SecureServlet Accessed");
-out.println("You have accessed this servlet as user:"+user+"");
-out.println("");
+out.println("You have accessed this servlet as user: "+user);
+out.println("You have accessed SecuredEJB as user: "+echoMsg);
+out.println("");
out.close();
}
1.1 jbosstest/src/main/org/jboss/test/web/servlets/DebugServlet.java
Index: DebugServlet.java
===
package org.jboss.test.web.servlets;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.URL;
import java.net.URLClassLoader;
import java.security.Principal;
import javax.naming.InitialContext;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/** A servlet that dumps out debugging information about its environment.
* @author [EMAIL PROTECTED]
* @version $Revision: 1.1 $
*/
public class DebugServlet extends HttpServlet
{
protected void processRequest(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
out.println("ENCServlet");
out.println("Debug Accessed");
out.println("");
out.println("ClassLoaders");
ClassLoader cl = Thread.currentThread().getContextClassLoader();
dumpClassLoader(cl, out);
out.println("JNDI");
try
{
InitialContext iniCtx = new InitialContext();
super.log("InitialContext.env: "+iniCtx.getEnvironment());
out.println("InitialContext.env: "+iniCtx.getEnvironment());
}
catch(Exception e)
{
super.log("Failed to create InitialContext", e);
}
out.println("");
out.close();
}
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
processRequest(request, response);
}
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
processRequest(request, response);
}
private v
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/ejb StatelessSessionBean.java
User: starksm
Date: 01/05/10 10:43:47
Modified:src/main/org/jboss/test/web/ejb StatelessSessionBean.java
Log:
Update the secured tests and add a DebugServlet
Revision ChangesPath
1.2 +2 -6
jbosstest/src/main/org/jboss/test/web/ejb/StatelessSessionBean.java
Index: StatelessSessionBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/ejb/StatelessSessionBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StatelessSessionBean.java 2001/05/05 20:59:35 1.1
+++ StatelessSessionBean.java 2001/05/10 17:43:47 1.2
@@ -11,7 +11,7 @@
/** A simple session bean for testing declarative security.
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.2 $
*/
public class StatelessSessionBean implements SessionBean
{
@@ -47,11 +47,7 @@
System.out.println("StatelessSessionBean.echo, arg="+arg);
Principal p = sessionContext.getCallerPrincipal();
System.out.println("StatelessSessionBean.echo, callerPrincipal="+p);
-boolean isCaller = sessionContext.isCallerInRole("EchoCaller");
-System.out.println("StatelessSessionBean.echo,
isCallerInRole('EchoCaller')="+isCaller);
-if( isCaller == false )
-throw new SecurityException("Caller does not have EchoCaller role");
-return arg;
+return p.getName();
}
public void noop(ReferenceTest test, boolean optimized)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web roles.properties users.properties
User: starksm Date: 01/05/10 10:42:44 Added: src/resources/web roles.properties users.properties Log: username, password and roles for the security tests Revision ChangesPath 1.1 jbosstest/src/resources/web/roles.properties Index: roles.properties === # org.jboss.security.auth.spi.UsersRolesLoginModule username to roles mapping jduke=AuthorizedUser guest=Anonymous 1.1 jbosstest/src/resources/web/users.properties Index: users.properties === # org.jboss.security.auth.spi.UsersRolesLoginModule username to password mapping jduke=theduke guest=guest ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web/WEB-INF jboss-web.xml web.xml
User: starksm Date: 01/05/10 10:41:56 Modified:src/resources/web/WEB-INF jboss-web.xml web.xml Log: Update the secured test settings Revision ChangesPath 1.2 +2 -0 jbosstest/src/resources/web/WEB-INF/jboss-web.xml Index: jboss-web.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/WEB-INF/jboss-web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss-web.xml 2001/05/05 20:56:55 1.1 +++ jboss-web.xml 2001/05/10 17:41:56 1.2 @@ -1,6 +1,8 @@ +java:/jaas/other + jdbc/DefaultDS javax.sql.DataSource 1.2 +8 -0 jbosstest/src/resources/web/WEB-INF/web.xml Index: web.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/WEB-INF/web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- web.xml 2001/05/05 20:56:55 1.1 +++ web.xml 2001/05/10 17:41:56 1.2 @@ -14,6 +14,10 @@ org.jboss.test.web.servlets.EJBServlet +DebugServlet +org.jboss.test.web.servlets.DebugServlet + + SecureServlet org.jboss.test.web.servlets.SecureServlet @@ -28,6 +32,10 @@ ENCServlet /ENCServlet + + +DebugServlet +/DebugServlet EJBServlet ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web index.html
User: starksm Date: 01/05/10 10:41:56 Modified:src/resources/web index.html Log: Update the secured test settings Revision ChangesPath 1.2 +5 -1 jbosstest/src/resources/web/index.html Index: index.html === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/index.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.html2001/05/05 20:56:55 1.1 +++ index.html2001/05/10 17:41:56 1.2 @@ -6,10 +6,14 @@ JBoss Servlet Container Integration Tests Servlet Tests + Try the DebugServlet + A debugging servlet that dumps out its request thread ClassLoaders +and the JNDI InitialContext environment. + Try the ENCServlet A test of the servlet container integration into the JNDI namespace. This servlet accesses the java:comp/env namespace for JDBC javax.sql.DataSources, - JMS QueueConnectionFactory, + JMS QueueConnectionFactory, EJBs, env variables, etc. Try the EJBServlet ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web/META-INF ejb-jar.xml
User: starksm Date: 01/05/10 10:41:56 Modified:src/resources/web/META-INF ejb-jar.xml Log: Update the secured test settings Revision ChangesPath 1.3 +31 -30jbosstest/src/resources/web/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/META-INF/ejb-jar.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-jar.xml 2001/05/06 04:13:44 1.2 +++ ejb-jar.xml 2001/05/10 17:41:56 1.3 @@ -39,36 +39,37 @@ - - -An anonymous unauthenticated user -Anonymous - - -An authenticated user -AuthorizedUser - + + + +An anonymous unauthenticated user +Anonymous + + +An authenticated user +AuthorizedUser + - - -Anonymous - -SecuredEJB -create - - -SecuredEJB -echo - - + + +Anonymous + +SecuredEJB +create + + +SecuredEJB +echo + + - - -AuthorizedUser - -SecuredEJB -* - - - + + +AuthorizedUser + +SecuredEJB +* + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Main.java, let's clean it up
How's about specifying the Configuration Service in the tag within the JCML file. Then the Main.java can start to read the JCML file and then hand it over to the found Configuration Service. MAD Andy > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 09, 2001 5:30 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Main.java, let's clean it up > > > We could get rid of jboss.conf if we put all the logging and > ClasspathExtension in jcml with a corresponding xml snippet. > We would still > need the conf or the main to set up the configuration service > (at least). > > marc > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On > Behalf Of Jason > |Dillon > |Sent: Wednesday, May 09, 2001 7:07 PM > |To: [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] Main.java, let's clean it up > | > | > |Is this going to include merging jboss.conf and jboss.jcml into > |one file (or > |perhaps using a standard jboss.conf from a class resource for > |boot-strapping) or will there still be two files? > | > |--jason > | > |On Wed, 9 May 2001, marc fleury wrote: > |> > |> |The setting of the security manager and server.policy file are > |> |better done from > |> |the command line as many security related events and > debugging hooks are > |> |done on startup of the vm. I don't think these should be > set at all from > |> |within the server. Setting the thread-local mode of the > |SecurityAssociation > |> |could be moved to an mbean. > |> > |> either command line or xml file. whichever you feel is more > |"admin friendly" > |> or both. > |> > |> I want to be done with the properties file asap. > |> > |> Let's simplify, the properties files is a big "ZIT" in our face > |and I want > |> to squeeze it "splatch" > |> > |> > |> h feels good doesn't it? > |> > |> |If I comment out the call to > DocumentBuilderFactory.newInstance() I am > |> |still able to switch the xml parsers using the JAXP properties so > |> |I don't see > |> |that this call has any effect other than preloading the parser > |classes. The > |> |xml parser settings could be moved to an MLet. > |> > |> kaay voodoo refactoring if I move this does it die? > |nope... ok > |> then... :) > |> > |> we should configure the xml stuff in a mlet as well, although it > |should be > |> one of the first ones (we do the mbean based on xml :) > |> > |> marc > |> > |> | > |> | > |> | > |> |___ > |> |Jboss-development mailing list > |> |[EMAIL PROTECTED] > |> |http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss/servlet container test suite???
> I think it would be nicer if performUndeploy() passed > me not the warUrl (since then I have to maintain a > table of warUrl to webApp, or look it up in yours) but > either the WebApplication object, or it's appData > (Jetty's WebApplicationContext). > Ok, how about the warUrl and WebApplication object. > DOM is not the fastest way of ripping information out > of an XML file. Do you really need the DOM object > hanging around afterwards, or would it be better to do > this via a lighter interface. > > Greg is already having to parse the web.xml file. He > is not using DOM, but SAX (AFAIK). Rather than reparse > the whole file again and allocate a DOM that will > later be chucked, could we not piggy-back on work > already being done by the WebContainer here. > DOM is the only interface used by all of the org.jboss.metadata objects that include the WebMetaData and nested objects which is really what is needed. A WebMetaData is a join of the information in the web-app.xml and jboss-web.xml descriptors. > As for the jboss-web.xml file, Jetty ignores this, so > it will be entirely up to me how I present it's > contents to you. > > What does Tomcat do here ? > Tomcat allows one to obtain the full paths of the WEB-INF/web-app.xml and WEB-INF/jboss-web.xml files and that is all. I have to parse these into the requisite DOM objects to build the WebMetaData object. > Perhaps we could offer several interfaces, so that > web-containers could choose the most suitable and > efficient one? > > What do you think? > You can't chain SAX parser handlers together can you such that both receive the parser events can you? Short of that I don't see any choice but to provide the DOM objects or equivalently InputStreams to their content as it does not make sense for the WebContainer to know how to create a WebMetaData from the web-app.xml and jboss-web.xml elements due to the JBoss specific semantics. If you have alternate interface suggestions go ahead and make them. Scott ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss/servlet container test suite???
--- Scott M Stark <[EMAIL PROTECTED]>
wrote: >
> > I think it would be nicer if performUndeploy()
> passed
> > me not the warUrl (since then I have to maintain a
> > table of warUrl to webApp, or look it up in yours)
> but
> > either the WebApplication object, or it's appData
> > (Jetty's WebApplicationContext).
> >
> Ok, how about the warUrl and WebApplication object.
>
If you want the warUrl, stick with it, there is no
need for both. I'll just use it as a lookup key.
> > DOM is not the fastest way of ripping information
> out
> > of an XML file. Do you really need the DOM object
> > hanging around afterwards, or would it be better
> to do
> > this via a lighter interface.
> >
> > Greg is already having to parse the web.xml file.
> He
> > is not using DOM, but SAX (AFAIK). Rather than
> reparse
> > the whole file again and allocate a DOM that will
> > later be chucked, could we not piggy-back on work
> > already being done by the WebContainer here.
> >
> DOM is the only interface used by all of the
> org.jboss.metadata objects
> that include the WebMetaData and nested objects
> which is really
> what is needed. A WebMetaData is a join of the
> information in the
> web-app.xml and jboss-web.xml descriptors.
>
> > As for the jboss-web.xml file, Jetty ignores this,
> so
> > it will be entirely up to me how I present it's
> > contents to you.
> >
> > What does Tomcat do here ?
> >
> Tomcat allows one to obtain the full paths of the
> WEB-INF/web-app.xml and
> WEB-INF/jboss-web.xml files and that is all.
That is pretty much what I have agreed with Greg.
> I have
> to parse these into the
> requisite DOM objects to build the WebMetaData
> object.
>
> > Perhaps we could offer several interfaces, so that
> > web-containers could choose the most suitable and
> > efficient one?
> >
> > What do you think?
> >
> You can't chain SAX parser handlers together can you
> such that both
> receive the parser events can you? Short of that I
> don't see any choice
> but to provide the DOM objects or equivalently
> InputStreams to their
> content as it does not make sense for the
> WebContainer to know how
> to create a WebMetaData from the web-app.xml and
> jboss-web.xml
> elements due to the JBoss specific semantics.
>
> If you have alternate interface suggestions go ahead
> and make them.
>
> Scott
>
For the proprietary descriptor it doesn't really
matter, since you will be the only person reading it.
You should use whatever is most appropriate.
It is probably simplest to deal with the standard
descriptor in the same way. I just thought it
worthwhile mentioning that this file will be parsed
twice, and that the way that I am currently learning
about ejb-refs from Jetty is via an
org.xml.sax.helpers.DefaultHandler which I register
using addContentHandler("ejb-ref", handler) on Jetty's
webApp's XmlParser. ejb-ref elements and their
subcomponents generate SAX events which bubble up to
my handler while Jetty is parsing the standard
descriptor. I don't know whether you can register only
one handler per tag-name or more, but Jetty doesn't
need to know about these ejb-refs anyway.
I'm happy to go with the existing interface.
Jules
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
http://lists.sourceforge.net/lists/listinfo/jboss-development
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss/servlet container test suite???
Scott, A couple of things that I noted whilst subclassing from AbstractWebContainer. I think it would be nicer if performUndeploy() passed me not the warUrl (since then I have to maintain a table of warUrl to webApp, or look it up in yours) but either the WebApplication object, or it's appData (Jetty's WebApplicationContext). DOM is not the fastest way of ripping information out of an XML file. Do you really need the DOM object hanging around afterwards, or would it be better to do this via a lighter interface. Greg is already having to parse the web.xml file. He is not using DOM, but SAX (AFAIK). Rather than reparse the whole file again and allocate a DOM that will later be chucked, could we not piggy-back on work already being done by the WebContainer here. As for the jboss-web.xml file, Jetty ignores this, so it will be entirely up to me how I present it's contents to you. What does Tomcat do here ? Perhaps we could offer several interfaces, so that web-containers could choose the most suitable and efficient one? What do you think? I shall have a look at the security stuff over the next couple of days. Thanks for your time, Jules --- Scott M Stark <[EMAIL PROTECTED]> wrote: > Actually I have the security integration working and > its pretty simple. > I have rewritten the tomcat3.2.1 mbean using it and > it is working so > I'll check in the updated AbstractWebContainer > tonight. > > - Original Message - > From: "Julian Gosnell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, May 09, 2001 5:05 PM > Subject: Re: [JBoss-dev] jboss/servlet container > test suite??? > > > > Scott, > > > > Thanks for the AbstractWebContainer - just what I > > need. > > > > I now have a version of JettyService inheriting > from > > this and implementing perform[Un]deploy(). > > > > I haven't checked it back in yet as I am passing > back > > the web.xml and jboss-web.xml Elements as null at > the > > moment and this is breaking deployment. > > > > Tomorrow (today) I shall talk to Greg about > exposing > > these through an interface that I can use and > > returning them to you. (I was adding a > ContentHandler > > to his XmlParser). As soon as we have that sorted > I > > shall check it all in. > > > > I have had interest expressed in the JAAS stuff as > > well, so am looking forward to sorting that out > with > > you soon. > > > > Please keep me posted, > > > > > > Jules > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Obscure issue (bug?) with CMP using column mapping
Hi,
I respond to dev for this one.
I do not think it is related to what you mention.
I use commit option C and the workaround still continue to work.
If I set "Optimized" to false, then I also do not see the problem.
I has already pass a lot of time to find what happens, and it looks like it
is due to classloader of EntityContext id object being not correct in the
case an entity bean A fBPK an entity B, both of them being in different
ejb-jar, then a session bean from ejb-jar A calls of fBPK on entity B and
remove() just after. if I call a remote method, the invoke() stuff reset
the classloader of id of entity context of the pool correctly.
Looks like the classloader of EntityContainer of A /or/ classloader of
ejb-jar A have put some mess in between.
Again, only with Optimized TRUE.
I'll continue to search - it makes me understand the architecture so I like
it ;)
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dan OConnor
> Envoyé : mercredi 9 mai 2001 0:13
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-user] Obscure issue (bug?) with CMP using column
> mapping
>
>
> The spec requires that the state of the bean is loaded before
> ejbRemove is called. The JBoss container is not doing this, in
> violation of the spec.
>
> Because commit option A is the default, the state of the bean will
> often already be loaded when ejbRemove is called, and the effects
> of this bug will not be visible.
>
> If the state is not already loaded, calling a "get" method will load
> the state, which will make it available in ejbRemove, assuming "A".
> (If you want to break your workaround, switch to commit "C".)
>
> Any volunteers to fix this?
>
> -Dan
>
> On 8 May 01, at 17:39, David Esposito wrote:
>
> > Vincent,
> >
> > You are my hero .. :) ... it works now ... it's always nice when the
> > workarounds are painless to integrate ... ;)
> >
> > Here's the snippet of code:
> >
> > joinRecords = repHome.findByRetailerID(params.memberCompanyID);}
> >
> > //Clear the table out for this company
> > while(joinRecords != null && joinRecords.hasMoreElements())
> > {
> > RepresentativeJoin joinRec =
> > (RepresentativeJoin)joinRecords.nextElement();
> >
> > log("Representative_ID = " + joinRec.getRepresentative());
> >
> > log("Deleting rec...");
> > joinRec.remove();
> > log("Delete succeeded...");
> > }
> >
> > if the first log() line is missing, the thing bombs out on
> remove() like I
> > described below ... with one call to the remote interface, the remove()
> > works smoothly ...
> >
> > Is this issue documented sufficiently for you to add it to the list of,
> > ahem, "known issues" or do you need me to explore it further?
> >
> > Thank you very much ...
> >
> > -Dave
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent
> > > Harcq
> > > Sent: Tuesday, May 08, 2001 4:38 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [JBoss-user] Obscure issue (bug?) with CMP using column
> > > mapping
> > >
> > >
> > > Hi,
> > > if you run remote= fBPK() then remote.remove(), can you try a
> > > remote.getanyfield() in between and let me know if it solve
> the problem or
> > > not. I also saw something similar to that.
> > > Thanks.
> > > Vincent.
> > >
> > > > -Message d'origine-
> > > > De : [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]De la part de David
> > > > Esposito
> > > > Envoyé : mardi 8 mai 2001 17:33
> > > > À : [EMAIL PROTECTED]
> > > > Objet : [JBoss-user] Obscure issue (bug?) with CMP using
> column mapping
> > > >
> > > >
> > > > Hello all,
> > > >
> > > > I have a weird situation:
> > > > JBOSS 2.2.1
> > > > Sun JDK 1.3
> > > > PostGreSQL 7.1 (although I have the same problem with Oracle 8.1.7)
> > > >
> > > > I have a CMP bean that is used to manipulate join tables
> ... (you know,
> > > > tables with only 2 columns used for a many-many
> relationship) ... rather
> > > > than create a half dozen beans, I have created only one and use the
> > > > deployment descriptor to map it to the appropriate table. All
> > > of my tables
> > > > contain 2 integer fields which, when concatenated, form the
> PK for the
> > > > table. So my deployment descriptors look like the following:
> > > >
> > > > From ejb-jar.xml:
> > > >
> > > >
> > > > Supplier_Representative
> > > >
> mypackage.ejb.representativejoin.RepresentativeJoinHome
> > > >
> mypackage.ejb.representativejoin.RepresentativeJoin
> > > >
> > > > mypackage.ejb.representativejoin.RepresentativeJoinBean
> > > > > > > s>
> > > > Container
> > > >
> > > > mypackage.ejb.representativejoin.RepresentativeJoi
> > > > nPK > > > key-class>
> > > > False
> > > >
> > > > representative_id
> > > > reference_id
> > > >
> > > >
> > > > Data source
> > > > jdbc/MyDB
> > > > javax.sql.DataSource
> > > > Container
> > > >
> > > >
> > > >
> > > > From jaws.xml:
> > > >
> > > >
> > > > Supplier_Representative
> > > >
[JBoss-dev] [ jboss-Patches-422932 ] connector module for J2eeDeployer
Patches item #422932, was updated on 2001-05-10 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=422932&group_id=22866 Category: JBossServer Group: v2.3 (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Claudio Vesco (cazzius) Assigned to: Nobody/Anonymous (nobody) Summary: connector module for J2eeDeployer Initial Comment: Hi! This is a patch file which permit the deployment of connector modules in EAR applications (application_1_3.dtd) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=422932&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
