[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource RARDeployer.java RARMetaData.java
User: starksm
Date: 01/11/02 00:38:08
Modified:src/main/org/jboss/resource Tag: Branch_2_4 RARDeployer.java
RARMetaData.java
Log:
Add the RAR jar files to the server MLet class loader on deployment to
make the adapapter available to all components.
Revision ChangesPath
No revision
No revision
1.3.2.2 +12 -31jbosscx/src/main/org/jboss/resource/RARDeployer.java
Index: RARDeployer.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARDeployer.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- RARDeployer.java 2001/09/30 22:44:26 1.3.2.1
+++ RARDeployer.java 2001/11/02 08:38:06 1.3.2.2
@@ -28,6 +28,7 @@
import java.util.jar.JarFile;
import javax.management.Notification;
+import javax.management.loading.MLet;
import org.jboss.deployment.DeployerMBeanSupport;
import org.jboss.deployment.DeploymentException;
@@ -46,7 +47,8 @@
*
* @author Toby Allsopp ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version$Revision: 1.3.2.1 $
+ * @author [EMAIL PROTECTED]
+ * @version$Revision: 1.3.2.2 $
* @seeorg.jboss.resource.ConnectionFactoryLoader p
*
* bRevisions:/b p
@@ -283,58 +285,38 @@
}
Document dd;
- try
- {
- dd = XmlFileLoader.getDocument(ddFile.toURL());
- }
- catch (org.jboss.ejb.DeploymentException de)
- {
- throw new DeploymentException(de.getMessage(), de.getCause());
- }
+ dd = XmlFileLoader.getDocument(ddFile.toURL());
Element root = dd.getDocumentElement();
RARMetaData metadata = new RARMetaData();
metadata.importXml(root);
- // Create a class loader that can load classes from any JARs
- // inside the RAR. First, we need to find the JARs.
-
+ // First, we need to find the JARs in the RAR archive
Collection jars = new ArrayList();
-
FileFilter filter =
new FileFilter()
{
-/**
- * #Description of the Method
- *
- * @param file Description of Parameter
- * @return Description of the Returned Value
- */
public boolean accept(File file)
{
return file.getName().endsWith(.jar);
}
};
Collection jarFiles = recursiveFind(unpackedDir, filter);
+ /* We need to make all of the RAR jars available to all components in the
+ app server so we need to add the jars to the main MLet class loader.
+ */
+ MLet mlet = (MLet) Thread.currentThread().getContextClassLoader();
category.debug(Adding the following URLs to classpath:);
for (Iterator i = jarFiles.iterator(); i.hasNext(); )
{
- File file = (File)i.next();
+ File file = (File) i.next();
URL jarUrl = file.toURL();
- jars.add(jarUrl);
category.debug(jarUrl.toString());
+ mlet.addURL(jarUrl);
}
+ metadata.setClassLoader(mlet);
- // Ok, now we have the URLs of the JARs contained in the RAR we
- // can create a classloader that loads classes from them
-
- ClassLoader cl = new URLClassLoader(
-(URL[])jars.toArray(new URL[0]),
-Thread.currentThread().getContextClassLoader());
-
- metadata.setClassLoader(cl);
-
// Let's tell the waiting hordes (of connection factory loaders)
// that this resource adapter is available
@@ -375,7 +357,6 @@
sendNotification(notification);
// Remove the temporary copy
-
File unpackedDir = info.unpackedDir;
if (!recursiveDelete(unpackedDir))
{
1.3.2.2 +10 -22jbosscx/src/main/org/jboss/resource/RARMetaData.java
Index: RARMetaData.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARMetaData.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- RARMetaData.java 2001/09/30 22:44:26 1.3.2.1
+++ RARMetaData.java 2001/11/02 08:38:07 1.3.2.2
@@ -25,7 +25,7 @@
*
* @author Toby Allsopp ([EMAIL PROTECTED])
* @seeRARDeployer
- * @version$Revision: 1.3.2.1 $
+ * @version$Revision: 1.3.2.2 $
*/
public class RARMetaData
// extends Y
@@ -278,8 +278,6 @@
private void setConfigProperty(Element element)
throws DeploymentException
{
- try
- {
Element nameE =
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommandFactory.java
User: starksm
Date: 01/11/02 00:42:33
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCCommandFactory.java
Log:
Remove org.jboss.ejb.DeploymentException in favor of
org.jboss.deploymen.DeploymentException
Revision ChangesPath
No revision
No revision
1.10.2.1 +2 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.10
retrieving revision 1.10.2.1
diff -u -r1.10 -r1.10.2.1
--- JDBCCommandFactory.java 2001/06/18 14:34:27 1.10
+++ JDBCCommandFactory.java 2001/11/02 08:42:33 1.10.2.1
@@ -24,7 +24,7 @@
import javax.transaction.TransactionManager;
import org.jboss.ejb.EntityContainer;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.plugins.jaws.JPMCommandFactory;
import org.jboss.ejb.plugins.jaws.JPMInitCommand;
@@ -68,7 +68,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=[EMAIL PROTECTED]danch (Dan Christopherson/a
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.10.2.1 $
*/
public class JDBCCommandFactory implements JPMCommandFactory
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management ContainerManagement.java
User: starksm Date: 01/11/02 00:42:36 Modified:src/main/org/jboss/management Tag: Branch_2_4 ContainerManagement.java Log: Remove org.jboss.ejb.DeploymentException in favor of org.jboss.deploymen.DeploymentException Revision ChangesPath No revision No revision 1.1.2.1 +0 -1 jboss/src/main/org/jboss/management/ContainerManagement.java Index: ContainerManagement.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/ContainerManagement.java,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- ContainerManagement.java 2001/06/16 05:48:44 1.1 +++ ContainerManagement.java 2001/11/02 08:42:36 1.1.2.1 @@ -38,7 +38,6 @@ import javax.management.MBeanServer; import javax.management.MBeanRegistration; import javax.management.ObjectName; -import javax.transaction.TransactionManager; import org.jboss.ejb.Container; @@ -62,7 +61,7 @@ * @see Container * @author Andreas Schaefer ([EMAIL PROTECTED]) * -* @version $Revision: 1.1 $ +* @version $Revision: 1.1.2.1 $ */ public class ContainerManagement extends org.jboss.util.ServiceMBeanSupport ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java AbstractWebContainerMBean.java
User: starksm
Date: 01/11/02 00:42:39
Modified:src/main/org/jboss/web Tag: Branch_2_4
AbstractWebContainer.java
AbstractWebContainerMBean.java
Log:
Remove org.jboss.ejb.DeploymentException in favor of
org.jboss.deploymen.DeploymentException
Revision ChangesPath
No revision
No revision
1.4.4.5 +2 -2 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.4.4.4
retrieving revision 1.4.4.5
diff -u -r1.4.4.4 -r1.4.4.5
--- AbstractWebContainer.java 2001/10/20 00:08:43 1.4.4.4
+++ AbstractWebContainer.java 2001/11/02 08:42:38 1.4.4.5
@@ -16,7 +16,7 @@
import org.apache.log4j.Category;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.EjbRefMetaData;
import org.jboss.metadata.EnvEntryMetaData;
import org.jboss.metadata.ResourceRefMetaData;
@@ -114,7 +114,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.4.4.4 $
+@version $Revision: 1.4.4.5 $
*/
public abstract class AbstractWebContainer extends ServiceMBeanSupport implements
AbstractWebContainerMBean
{
1.1.6.1 +3 -3 jboss/src/main/org/jboss/web/AbstractWebContainerMBean.java
Index: AbstractWebContainerMBean.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainerMBean.java,v
retrieving revision 1.1
retrieving revision 1.1.6.1
diff -u -r1.1 -r1.1.6.1
--- AbstractWebContainerMBean.java2001/05/09 07:11:16 1.1
+++ AbstractWebContainerMBean.java2001/11/02 08:42:39 1.1.6.1
@@ -2,12 +2,12 @@
import java.util.Iterator;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
/** A template pattern for web container integration into JBoss.
-@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.1.6.1 $
*/
public interface AbstractWebContainerMBean extends org.jboss.util.ServiceMBean
{
___
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/jms JMSContainerInvoker.java
User: starksm Date: 01/11/02 00:42:34 Modified:src/main/org/jboss/ejb/plugins/jms Tag: Branch_2_4 JMSContainerInvoker.java Log: Remove org.jboss.ejb.DeploymentException in favor of org.jboss.deploymen.DeploymentException Revision ChangesPath No revision No revision 1.12.4.4 +2 -2 jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java Index: JMSContainerInvoker.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v retrieving revision 1.12.4.3 retrieving revision 1.12.4.4 diff -u -r1.12.4.3 -r1.12.4.4 --- JMSContainerInvoker.java 2001/10/22 10:19:33 1.12.4.3 +++ JMSContainerInvoker.java 2001/11/02 08:42:34 1.12.4.4 @@ -41,7 +41,7 @@ import org.jboss.ejb.ContainerInvokerContainer; import org.jboss.ejb.Interceptor; import org.jboss.ejb.ContainerInvoker; -import org.jboss.ejb.DeploymentException; +import org.jboss.deployment.DeploymentException; import org.jboss.metadata.XmlLoadable; import org.jboss.metadata.MetaData; @@ -60,7 +60,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a - * @version $Revision: 1.12.4.3 $ + * @version $Revision: 1.12.4.4 $ */ public class JMSContainerInvoker implements ContainerInvoker, XmlLoadable ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java BeanMetaData.java ConfigurationMetaData.java EjbLocalRefMetaData.java EjbRefMetaData.java EntityMetaData.java EnvEntryMetaData.java MessageDrivenMetaData.java MetaData.java MethodMetaData.java ResourceEnvRefMetaData.java ResourceRefMetaData.java SecurityIdentityMetaData.java SecurityRoleRefMetaData.java SessionMetaData.java WebMetaData.java XmlFileLoader.java
User: starksm
Date: 01/11/02 00:42:37
Modified:src/main/org/jboss/metadata Tag: Branch_2_4
ApplicationMetaData.java BeanMetaData.java
ConfigurationMetaData.java EjbLocalRefMetaData.java
EjbRefMetaData.java EntityMetaData.java
EnvEntryMetaData.java MessageDrivenMetaData.java
MetaData.java MethodMetaData.java
ResourceEnvRefMetaData.java
ResourceRefMetaData.java
SecurityIdentityMetaData.java
SecurityRoleRefMetaData.java SessionMetaData.java
WebMetaData.java XmlFileLoader.java
Log:
Remove org.jboss.ejb.DeploymentException in favor of
org.jboss.deploymen.DeploymentException
Revision ChangesPath
No revision
No revision
1.16.4.2 +3 -3 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.16.4.1
retrieving revision 1.16.4.2
diff -u -r1.16.4.1 -r1.16.4.2
--- ApplicationMetaData.java 2001/06/22 04:09:32 1.16.4.1
+++ ApplicationMetaData.java 2001/11/02 08:42:36 1.16.4.2
@@ -17,7 +17,7 @@
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
/** The top level meta data from the jboss.xml descriptor.
@@ -26,8 +26,8 @@
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
- * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
- * @version $Revision: 1.16.4.1 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.16.4.2 $
*/
public class ApplicationMetaData extends MetaData
{
1.23.2.2 +2 -2 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.23.2.1
retrieving revision 1.23.2.2
diff -u -r1.23.2.1 -r1.23.2.2
--- BeanMetaData.java 2001/09/04 01:52:06 1.23.2.1
+++ BeanMetaData.java 2001/11/02 08:42:36 1.23.2.2
@@ -16,7 +16,7 @@
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
import org.jboss.security.AnybodyPrincipal;
import org.jboss.security.NobodyPrincipal;
import org.jboss.security.SimplePrincipal;
@@ -29,7 +29,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Daniel OConnor/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.23.2.1 $
+ * @version $Revision: 1.23.2.2 $
*/
public abstract class BeanMetaData
extends MetaData
1.14.2.2 +234 -205 jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java
Index: ConfigurationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- ConfigurationMetaData.java2001/09/04 01:52:06 1.14.2.1
+++ ConfigurationMetaData.java2001/11/02 08:42:36 1.14.2.2
@@ -8,218 +8,247 @@
import org.w3c.dom.Element;
-import org.jboss.ejb.DeploymentException;
+import org.jboss.deployment.DeploymentException;
/** The configuration information for an EJB container.
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.14.2.1 $
+ * @version $Revision: 1.14.2.2 $
*/
-public class ConfigurationMetaData extends MetaData {
-
- // Constants -
-public static final String CMP_13 = Standard CMP EntityBean;
- public static final String BMP_13 = Standard BMP EntityBean;
- public static final String STATELESS_13 = Standard Stateless SessionBean;
- public static final String STATEFUL_13 = Standard Stateful SessionBean;
- public static final String MESSAGE_DRIVEN_13 = Standard Message Driven Bean;
-public static final String CMP_12 = jdk1.2.2 CMP EntityBean;
- public static final String BMP_12 = jdk1.2.2 BMP EntityBean;
- public static final String STATELESS_12 = jdk1.2.2 Stateless SessionBean;
- public static final String STATEFUL_12 = jdk1.2.2
WG: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException
Arrrgh, the reply-to PITA (pain in the ass). -Ursprüngliche Nachricht- Von: Jung , Dr. Christoph Gesendet: Freitag, 2. November 2001 09:55 An: 'Scott M Stark' Betreff: AW: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Why not have the ejb.DeploymentException being a subclass of deployment.DeploymentException? This still allows to discriminate the source deployer and at the same time releaves you from the burden to catch it int the interface between J2eeDeployer and ContainerFactory ... IMHO, there can be never enough exceptions to enable a flexible error treatment, but they need to expose more structure in order to ease default behaviour ... CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 2. November 2001 05:58 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Both 2.4.4 and 3.0 - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 7:33 PM Subject: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Yippee!!! Is this for jboss 3 I hope? david jencks On 2001.11.01 22:13:42 -0500 Scott M Stark wrote: We have two equivalent exceptions org.jboss.deployment.DeploymentException and org.jboss.ejb.DeploymentException. In a number of places we have to catch a org.jboss.ejb.DeploymentException just to rethrow it as a org.jboss.deployment.DeploymentException. Very ugly. I'm going to drop the ejb package version in favor of the more general org.jboss.deployment.DeploymentException version. Speak now or kiss the ejb version goodbye. Scott Stark Chief Technology Officer JBoss Group, LLC ___ 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosscx.jar
User: starksm Date: 01/11/02 01:05:45 Modified:src/lib Tag: Branch_2_4 jbosscx.jar Log: Include Rel_2_4_4_9 JBossCX changes Revision ChangesPath No revision No revision 1.1.2.3 +119 -127 jboss/src/lib/Attic/jbosscx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException
Maybe in 3.0 if it really adds something. An ejb specific exception without any new data doesn't do anything for me. org.jboss.ejb.DeploymentException is gone from 2.4. -Ursprüngliche Nachricht- Von: Jung , Dr. Christoph Gesendet: Freitag, 2. November 2001 09:55 An: 'Scott M Stark' Betreff: AW: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Why not have the ejb.DeploymentException being a subclass of deployment.DeploymentException? This still allows to discriminate the source deployer and at the same time releaves you from the burden to catch it int the interface between J2eeDeployer and ContainerFactory ... IMHO, there can be never enough exceptions to enable a flexible error treatment, but they need to expose more structure in order to ease default behaviour ... CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 2. November 2001 05:58 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Both 2.4.4 and 3.0 - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 7:33 PM Subject: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Yippee!!! Is this for jboss 3 I hope? david jencks On 2001.11.01 22:13:42 -0500 Scott M Stark wrote: We have two equivalent exceptions org.jboss.deployment.DeploymentException and org.jboss.ejb.DeploymentException. In a number of places we have to catch a org.jboss.ejb.DeploymentException just to rethrow it as a org.jboss.deployment.DeploymentException. Very ugly. I'm going to drop the ejb package version in favor of the more general org.jboss.deployment.DeploymentException version. Speak now or kiss the ejb version goodbye. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException
-Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 2. November 2001 10:19 An: Jboss-Development (E-Mail) Betreff: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Maybe in 3.0 if it really adds something. An ejb specific exception without any new data doesn't do anything for me. org.jboss.ejb.DeploymentException is gone from 2.4. At the danger of being too esoteric, it adds at least the information that the exception has been thrown from a specific deployer or from a particular deployment facility/package, namely the ContainerFactory. I´m always thinking of mabye one day, someone will need to catch extactly those and let other DeploymentExceptions pass through. Furthermore, I like nesting of exceptions in a multi-tiered environment (one thing that JDK1.4 does IMHO right) ... with subclassing you can inherit the important nesting code from a root exception class to various places in the system - but thats not our topic, sorry. Maybe we could decide about a general exception guideline for 3.0 ? But its not urgent. CGJ -Ursprüngliche Nachricht- Von: Jung , Dr. Christoph Gesendet: Freitag, 2. November 2001 09:55 An: 'Scott M Stark' Betreff: AW: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Why not have the ejb.DeploymentException being a subclass of deployment.DeploymentException? This still allows to discriminate the source deployer and at the same time releaves you from the burden to catch it int the interface between J2eeDeployer and ContainerFactory ... IMHO, there can be never enough exceptions to enable a flexible error treatment, but they need to expose more structure in order to ease default behaviour ... CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 2. November 2001 05:58 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Both 2.4.4 and 3.0 - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 7:33 PM Subject: Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException Yippee!!! Is this for jboss 3 I hope? david jencks On 2001.11.01 22:13:42 -0500 Scott M Stark wrote: We have two equivalent exceptions org.jboss.deployment.DeploymentException and org.jboss.ejb.DeploymentException. In a number of places we have to catch a org.jboss.ejb.DeploymentException just to rethrow it as a org.jboss.deployment.DeploymentException. Very ugly. I'm going to drop the ejb package version in favor of the more general org.jboss.deployment.DeploymentException version. Speak now or kiss the ejb version goodbye. ___ 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] The RARDeployer classpath is broken
Wonderful, this will help one of my projects a great deal. Thanks! david On 2001.11.02 00:02:08 -0500 Scott M Stark wrote: - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 7:09 PM Subject: Re: [JBoss-dev] The RARDeployer classpath is broken What is wrong with the RARDeployer adding the rar jars to the server classpath? This is what jboss 3 does. Is there a way to do this in jboss 2.4? I don't know what it is. It can be done in the same fashion as the ClassPathExtension mbean that adds urls to the MLet class loader used as the server main class loader. I'm testing this out for 2.4. ___ 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: newsite build.xml
User: mnf999
Date: 01/11/02 07:19:53
Modified:.build.xml
Log:
build.xml for the current website
Revision ChangesPath
1.22 +17 -30newsite/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/newsite/build.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- build.xml 2001/11/02 04:05:41 1.21
+++ build.xml 2001/11/02 15:19:53 1.22
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.21 2001/11/02 04:05:41 mnf999 Exp $ --
+!-- $Id: build.xml,v 1.22 2001/11/02 15:19:53 mnf999 Exp $ --
project default=main name=JBoss Website/Website
@@ -259,9 +259,8 @@
depends=init,
compile-docs,
compile-metadata,
- compile-bin/
-!--,
- compile-snapshots/--
+ compile-bin,
+ compile-snapshots/
!-- Compile doc sources support files --
target name=compile-docs depends=init
@@ -309,16 +308,14 @@
!-- Export the cvs modules for snapshots --
-!--
target name=_compile-snapshots-export-cvs
depends=init
unless=snapshot-export-cvs.disable
mkdir dir=${build.snapshots.tmp}/
echoExporting CVS modules for snaphots.../echo
---
+
!-- Make sure there is an entry for this cvsroot --
-!--
cvspass cvsroot=${snapshot.cvsroot} password=/
cvs cvsroot=${snapshot.cvsroot}
@@ -327,27 +324,26 @@
package=${snapshot.modules}
dest=${build.snapshots.tmp}/
/target
---
!-- Compile cvs source snapshots --
-!--
+
target name=compile-snapshots
unless=snapshot.disable
depends=init, _compile-snapshots-export-cvs
mkdir dir=${build.snapshots}/
---
+
!-- build jboss-all.zip --
-!--
+
zip zipfile=${build.snapshots}/jboss-all.zip
fileset dir=${build.snapshots.tmp}
include name=jboss-all/**/
/fileset
/zip
---
+
!-- build jboss-all.tgz --
-!--
+
tar tarfile=${build.snapshots}/jboss-all.tar
longfile=gnu
basedir=${build.snapshots.tmp}
@@ -355,18 +351,18 @@
/tar
gzip src=${build.snapshots}/jboss-all.tar
zipfile=${build.snapshots}/jboss-all.tgz/
---
+
!-- build jboss-mq.zip --
-!--
+
zip zipfile=${build.snapshots}/jboss-mq.zip
fileset dir=${build.snapshots.tmp}
include name=jboss-mq/**/
/fileset
/zip
---
+
!-- build jboss-mq.tgz --
-!--
+
tar tarfile=${build.snapshots}/jboss-mq.tar
longfile=gnu
basedir=${build.snapshots.tmp}
@@ -374,19 +370,16 @@
/tar
gzip src=${build.snapshots}/jboss-mq.tar
zipfile=${build.snapshots}/jboss-mq.tgz/
---
+
!-- build jboss-plugins.zip --
-!--
zip zipfile=${build.snapshots}/jboss-plugins.zip
fileset dir=${build.snapshots.tmp}
include name=jboss-plugins/**/
/fileset
/zip
---
!-- build jboss-plugins.tgz --
-!--
tar tarfile=${build.snapshots}/jboss-plugins.tar
longfile=gnu
basedir=${build.snapshots.tmp}
@@ -394,7 +387,7 @@
/tar
gzip src=${build.snapshots}/jboss-plugins.tar
zipfile=${build.snapshots}/jboss-plugins.tgz/
---
+
!-- = --
!-- HACK Make the JBoss DTDs available under j2ee/dtd --
!-- = --
@@ -404,7 +397,7 @@
| perhaps the dtds should be in a seperate module (shared by jboss-all
| and jboss-website), or something... this is just bad form!
--
-!--
+
mkdir dir=${build.docs}/j2ee/dtd/
copy todir=${build.docs}/j2ee/dtd filtering=no
fileset
dir=${build.snapshots.tmp}/jboss-all/server/src/resources/org/jboss/metadata
@@ -413,7 +406,7 @@
/copy
/target
---
+
!-- == --
!-- Archives --
!-- == --
@@ -455,12 +448,6 @@
include name=snapshots.war/
/fileset
/ear
-
- copy todir=/home/marcf/JBoss-2.4.1_Tomcat-3.2.3/jboss/deploy filtering=no
- fileset dir=${build.lib}
- include name=website.ear/
- /fileset
-/copy
/target
___
[JBoss-dev] SpyTextMessage StringBuffer allocation!? (Memory Overload!)
I'm busy trying to run our application using JBossMQ and were having some sever memory problems with our application. I've been using OptimizeIt to track down what happening, and I've found that the class SpyTextMessage is using a java.lang.StringBuffer class to read int the UTF text from the ObjectInputStream. For some reason the initial capacity is set to 16K and the comment implies a bug for Strings greater than 64K in Java 1.3.*. From a first blush look one would think that the StringBuffer.toString() would optimize the memory use and chop the buffer size down. But based upon the information I got from OptimizeIt, the toString() method just wraps the already allocated char[] buffer in a String class. The main problem with this is that most of our text message are less that a few hundred bytes. The 16K buffer is killing the MQ server since we send a VERY large number of messages. I'm using the IBM 1.3 JDK: [root@linux-weave-1 OpenNMS]# /opt/IBMJava2-13/bin/java -version java version 1.3.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) Attached are some exported data from the OptimizIt run. Weave Allocation backtraces for class char[]. application org.jboss.Main -- Backtrace of code allocating char[] --- 19025 instances of char[] allocated. 80.64% java.lang.Thread.run() (Thread.java:498) 69.67% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:213) 62.57% org.jboss.mq.SpyMessage.readMessage() (SpyMessage.java:600) 49.4% org.jboss.mq.SpyTextMessage.readExternal() (SpyTextMessage.java:65) 16.42% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:691) 16.42% org.jboss.mq.SpyMessage.readString() (SpyMessage.java:683) 13.61% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:712) 8.21% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:707) 6.18% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:738) 4.96% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:687) 0.01% org.jboss.mq.SpyMessage.readExternal() (SpyMessage.java:702) 8.21% org.jboss.mq.SpyTextMessage.readExternal() (SpyTextMessage.java:76) 8.21% java.lang.StringBuffer.StringBuffer() (StringBuffer.java:122) 4.95% org.jboss.mq.SpyTextMessage.readExternal() (SpyTextMessage.java:78) 4.95% java.io.ObjectInputStream.readUTF() (ObjectInputStream.java:2112) 3.96% java.io.ObjectInputStream.readUTFBody() (ObjectInputStream.java:2204) 0.73% java.io.ObjectInputStream.readUTFBody() (ObjectInputStream.java:2201) 0.18% java.io.ObjectInputStream.readUTFBody() (ObjectInputStream.java:2155) 0.06% java.io.ObjectInputStream.readUTFBody() (ObjectInputStream.java:2127) 7.1% org.jboss.mq.server.JMSServer.addMessage() (JMSServer.java:381) 3.55% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:209) 2.16% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:255) 1.09% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:254) 0.85% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:284) 0.52% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:204) 0.44% sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (TCPTransport.java:662) 0.42% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:267) 0.42% org.jboss.deployment.AutoDeployer.run() (AutoDeployer.java:251) 0.39% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:235) 0.26% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:250) 0.25% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:247) 0.19% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:161) 0.13% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:165) 0.03% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:148) 0.03% org.jboss.mq.il.uil.UILServerILService.run() (UILServerILService.java:149) 0.03% sun.rmi.transport.tcp.TCPTransport.run() (TCPTransport.java:338) 0.02% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:210) 0.02% sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (TCPTransport.java:658) 0.02% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:238) 0.01% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:258) 0.01% org.jboss.mq.il.oil.OILServerILService.run() (OILServerILService.java:222) 0.01%
[JBoss-dev] Jetty + JBoss getting started
Hi, probably that's the most FAQ question around, but I checked both the list archive and the forum (honestly!), and couldn't find any answer. I've got the latest JBoss+Jetty package (JBoss-2.4.3_Jetty-3.1.3-1.zip) from sourceforge, unpacked, chmod-ed, ran ./run.sh, and the whole started up successfully; however at http://localhost:8080, or at any url based on that (eg. /jetty or /jboss) all I get is a 404 page from Jetty. If I run Jetty standalone, (starting with 'jetty.sh start'), I've got a valid response and jetty serves the pages correctly. Now, as I've got it out of the box, I guess it should be some integration problem. Please give me an advice what I've did wrong.. My setup: IBM JDK 1.3 on debian linux (sid), environment variables (JAVA_HOME, JBOSS_DIST, JETTY_HOME) correctly set. Thanks in advance, Christopher ps. in the included README file Jules wrote that's the correct place to report/ask questions about JBoss and Jetty integration, I hope I wasn't horribly offtopic :) -- .Digital.Yearning.for.Networked.Assassination.and.Xenocide ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] SpyTextMessage StringBuffer allocation!? (Memory Overload!)
oops fired a bit early... I will still give you rw but please follow Scott's
recommendation
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Friday, November 02, 2001 12:29 PM
|To: Brian Weaver; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] SpyTextMessage StringBuffer allocation!?
|(Memory Overload!)
|
|
|We shouldn't even be allocating a big buffer unless there are multiple
|chunks to read. Try this change and if it works I'll commit it.
|
|[starksm@banshee mq]$ cvs diff SpyTextMessage.java
|Index: SpyTextMessage.java
|===
|RCS file:
|/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTextMessage.java,v
|retrieving revision 1.4
|diff -r1.4 SpyTextMessage.java
|76c76,79
| StringBuffer sb = new StringBuffer(chunkSize * chunksToRead);
|---
| int bufferSize = chunkSize * chunksToRead;
| if( chunksToRead = 1 )
| bufferSize = Math.min(in.available(), bufferSize);
| StringBuffer sb = new StringBuffer(bufferSize);
|80c83
| content = sb.toString();
|---
| content = sb.substring(0, sb.length());
|
|
|
|Scott Stark
|Chief Technology Officer
|JBoss Group, LLC
|
|- Original Message -
|From: Brian Weaver [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Sent: Friday, November 02, 2001 8:39 AM
|Subject: Re: [JBoss-dev] SpyTextMessage StringBuffer allocation!? (Memory
|Overload!)
|
|
| I just made a simple fix to the SpyTextMessage class and it dropped the
| memory usage drasticly. Here is the context diff.
|
| Weave
|
| diff -urN --exclude=CVS
|jboss-mq/messaging/src/main/org/jboss/mq/SpyTextMessage.java
|jboss-mq.onms/messaging/src/main/org/jboss/mq/SpyTextMessage.java
| --- jboss-mq/messaging/src/main/org/jboss/mq/SpyTextMessage.java
|Sun Oct 28 00:07:34 2001
| +++ jboss-mq.onms/messaging/src/main/org/jboss/mq/SpyTextMessage.java
|Fri Nov 2 11:03:10 2001
| @@ -77,7 +77,7 @@
| for (int i = 0; i chunksToRead; i++) {
|sb.append( in.readUTF() );
| }
| - content = sb.toString();
| + content = sb.substring(0, sb.length());
|}
| }
|
|
| Brian Weaver [[EMAIL PROTECTED]] wrote:
| I'm busy trying to run our application using JBossMQ and were having
| some sever memory problems with our application. I've been using
|OptimizeIt
| to track down what happening, and I've found that the class
|SpyTextMessage
| is using a java.lang.StringBuffer class to read int the UTF text from
|the
| ObjectInputStream.
|
| For some reason the initial capacity is set to 16K and the comment
| implies a bug for Strings greater than 64K in Java 1.3.*. From a first
| blush look one would think that the StringBuffer.toString() would
| optimize the memory use and chop the buffer size down. But based upon
| the information I got from OptimizeIt, the toString() method just wraps
| the already allocated char[] buffer in a String class.
|
| The main problem with this is that most of our text message are less
|that
| a few hundred bytes. The 16K buffer is killing the MQ server since we
|send
| a VERY large number of messages.
|
| I'm using the IBM 1.3 JDK:
|
| [root@linux-weave-1 OpenNMS]# /opt/IBMJava2-13/bin/java -version
| java version 1.3.0
| Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
| Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT
|enabled: jitc))
|
|
| Attached are some exported data from the OptimizIt run.
|
| Weave
|
|
| Allocation backtraces for class char[]. application org.jboss.Main
| --
|
| Backtrace of code allocating char[]
| ---
|
| 19025 instances of char[] allocated.
| 80.64% java.lang.Thread.run() (Thread.java:498)
|69.67% org.jboss.mq.il.oil.OILServerILService.run()
|(OILServerILService.java:213)
| 62.57% org.jboss.mq.SpyMessage.readMessage()
|(SpyMessage.java:600)
| 49.4% org.jboss.mq.SpyTextMessage.readExternal()
|(SpyTextMessage.java:65)
| 16.42% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:691)
|16.42% org.jboss.mq.SpyMessage.readString()
|(SpyMessage.java:683)
| 13.61% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:712)
| 8.21% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:707)
| 6.18% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:738)
| 4.96% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:687)
| 0.01% org.jboss.mq.SpyMessage.readExternal()
|(SpyMessage.java:702)
| 8.21% org.jboss.mq.SpyTextMessage.readExternal()
|(SpyTextMessage.java:76)
| 8.21% java.lang.StringBuffer.StringBuffer()
|(StringBuffer.java:122)
| 4.95%
[JBoss-dev] CVS update: newsite/src/metadata jbossgroup-web.xml
User: mnf999 Date: 01/11/02 09:30:42 Removed: src/metadata jbossgroup-web.xml Log: ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/metadata website-application.xml
User: mnf999 Date: 01/11/02 09:29:54 Modified:src/metadata website-application.xml Log: Revision ChangesPath 1.3 +1 -8 newsite/src/metadata/website-application.xml Index: website-application.xml === RCS file: /cvsroot/jboss/newsite/src/metadata/website-application.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- website-application.xml 2001/09/28 03:23:00 1.2 +++ website-application.xml 2001/11/02 17:29:54 1.3 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=UTF-8? !DOCTYPE application -!-- $Id: website-application.xml,v 1.2 2001/09/28 03:23:00 user57 Exp $ -- +!-- $Id: website-application.xml,v 1.3 2001/11/02 17:29:54 mnf999 Exp $ -- application display-nameJBoss Website/display-name @@ -10,13 +10,6 @@ web web-uriwebsite.war/web-uri context-root//context-root - /web - /module - - module - web - web-urijbossgroup.war/web-uri - context-root/JBG/context-root /web /module ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite build.xml
User: mnf999
Date: 01/11/02 09:29:54
Modified:.build.xml
Log:
Revision ChangesPath
1.23 +1 -10 newsite/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/newsite/build.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- build.xml 2001/11/02 15:19:53 1.22
+++ build.xml 2001/11/02 17:29:53 1.23
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.22 2001/11/02 15:19:53 mnf999 Exp $ --
+!-- $Id: build.xml,v 1.23 2001/11/02 17:29:53 mnf999 Exp $ --
project default=main name=JBoss Website/Website
@@ -421,17 +421,9 @@
webxml=${build.metadata}/website-web.xml
fileset dir=${build.docs}
include name=**/*/
-exclude name=jbossgroup/
/fileset
/war
-war warfile=${build.lib}/jbossgroup.war
- webxml=${build.metadata}/jbossgroup-web.xml
- fileset dir=${build.docs}/jbossgroup
-include name=**/*/
- /fileset
-/war
-
war warfile=${build.lib}/snapshots.war
webxml=${build.metadata}/snapshots-web.xml
fileset dir=${build.snapshots}
@@ -444,7 +436,6 @@
appxml=${build.metadata}/website-application.xml
fileset dir=${build.lib}
include name=website.war/
-include name=jbossgroup.war/
include name=snapshots.war/
/fileset
/ear
___
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/cmp/jdbc JDBCCreateEntityCommand.java JDBCLoadEntityCommand.java
User: dsundstrom Date: 01/11/02 10:24:25 Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCCreateEntityCommand.java JDBCLoadEntityCommand.java Log: Now marks the bean as created after successful execution. Revision ChangesPath 1.4 +4 -1 jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java Index: JDBCCreateEntityCommand.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JDBCCreateEntityCommand.java 2001/09/01 22:03:15 1.3 +++ JDBCCreateEntityCommand.java 2001/11/02 18:24:25 1.4 @@ -37,7 +37,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a * @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a - * @version $Revision: 1.3 $ + * @version $Revision: 1.4 $ */ public class JDBCCreateEntityCommand extends JDBCUpdateCommand @@ -93,6 +93,9 @@ log.debug(e); throw new CreateException(Could not create entity: + e); } + + // mark the entity as created + entity.setCreated(ctx); return id; } 1.5 +4 -1 jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadEntityCommand.java Index: JDBCLoadEntityCommand.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadEntityCommand.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- JDBCLoadEntityCommand.java2001/10/09 00:29:43 1.4 +++ JDBCLoadEntityCommand.java2001/11/02 18:24:25 1.5 @@ -39,7 +39,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ */ public class JDBCLoadEntityCommand extends JDBCQueryCommand @@ -69,6 +69,9 @@ throw new ServerException(Load failed, e); } } + + // mark the entity as created; if it was loaded it was created + entity.setCreated(ctx); } // JDBCQueryCommand overrides ___ 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/cmp/jdbc/bridge NewQueuedPessimisticEJBLock.java
User: dsundstrom Date: 01/11/02 13:14:42 Removed: src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge NewQueuedPessimisticEJBLock.java Log: Code integrated into org.jboss.ejb.plugins.lock.BeanLockSupport ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client DynamicStub.java
User: reverbel
Date: 01/11/02 13:17:42
Modified:iiop/src/main/org/jboss/ejb/plugins/iiop/client
DynamicStub.java
Log:
Changed from protected to public all methods of the DynamicStub base class
that must be seen (by reflection) by the ProxyAssembler.
Revision ChangesPath
1.2 +20 -20
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java
Index: DynamicStub.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DynamicStub.java 2001/08/28 22:19:00 1.1
+++ DynamicStub.java 2001/11/02 21:17:42 1.2
@@ -30,7 +30,7 @@
* of operation parameters.
*
* @author a href=mailto:[EMAIL PROTECTED];Francisco Reverbel/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public abstract class DynamicStub
extends ObjectImpl
@@ -46,14 +46,14 @@
super();
}
- // Protected methods used by dynamically generated IIOP stubs --
+ // Methods used by dynamically generated IIOP stubs
/**
* Sends a request message to the server, receives the reply from the
* server, and returns an codeObject/code result to the caller.
*/
- protected Object invoke(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public Object invoke(String operationName,
+StubStrategy stubStrategy, Object[] params)
throws Throwable
{
InputStream in = null;
@@ -97,8 +97,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns a codeboolean/code result to the caller.
*/
- protected boolean invokeBoolean(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public boolean invokeBoolean(String operationName,
+StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Boolean)invoke(operationName,
@@ -109,8 +109,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns a codebyte/code result to the caller.
*/
- protected byte invokeByte(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public byte invokeByte(String operationName,
+ StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Number)invoke(operationName,
@@ -121,8 +121,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns a codechar/code result to the caller.
*/
- protected char invokeChar(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public char invokeChar(String operationName,
+ StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Character)invoke(operationName,
@@ -133,8 +133,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns a codeshort/code result to the caller.
*/
- protected short invokeShort(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public short invokeShort(String operationName,
+StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Number)invoke(operationName,
@@ -145,8 +145,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns an codeint/code result to the caller.
*/
- protected int invokeInt(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public int invokeInt(String operationName,
+StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Number)invoke(operationName, stubStrategy, params)).intValue();
@@ -156,8 +156,8 @@
* Sends a request message to the server, receives the reply from the
* server, and returns a codelong/code result to the caller.
*/
- protected long invokeLong(String operationName,
- StubStrategy stubStrategy, Object[] params)
+ public long invokeLong(String operationName,
+ StubStrategy stubStrategy, Object[] params)
throws Throwable
{
return ((Number)invoke(operationName, stubStrategy, params)).longValue();
@@ -167,8 +167,8 @@
*
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjboss.xml
User: dsundstrom Date: 01/11/02 13:19:12 Modified:src/etc/conf/default standardjboss.xml Log: Changed CMP 2.0 Entities back to use org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock. Revision ChangesPath 1.24 +2 -3 jboss/src/etc/conf/default/standardjboss.xml Index: standardjboss.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- standardjboss.xml 2001/10/21 03:21:03 1.23 +++ standardjboss.xml 2001/11/02 21:19:12 1.24 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjboss.xml,v 1.23 2001/10/21 03:21:03 dsundstrom Exp $ -- +!-- $Id: standardjboss.xml,v 1.24 2001/11/02 21:19:12 dsundstrom Exp $ -- jboss enforce-ejb-restrictionsfalse/enforce-ejb-restrictions @@ -32,8 +32,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager -!-- locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy -- - locking-policyorg.jboss.ejb.plugins.cmp.jdbc.bridge.NewQueuedPessimisticEJBLock/locking-policy + locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy container-invoker-conf OptimizedTrue/Optimized RMIObjectPort/RMIObjectPort ___ 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/cmp/jdbc/ejbql EJBQLParser.java
User: dsundstrom
Date: 01/11/02 13:20:29
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql
EJBQLParser.java
Log:
Added support for input parameters in collection_member_expression as is
required in the EJB 2.0 Final Draft.
Revision ChangesPath
1.6 +23 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/EJBQLParser.java
Index: EJBQLParser.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/EJBQLParser.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EJBQLParser.java 2001/09/01 22:03:17 1.5
+++ EJBQLParser.java 2001/11/02 21:20:29 1.6
@@ -497,12 +497,20 @@
return emptyColCompExp;
}
- // collection_member_expression ::= single_valued_path_expression [NOT ]MEMBER
[OF ] collection_valued_path_expression
+ // collection_member_expression ::=
+ // {single_valued_navigation | identification_variable | input_parameter}
+ // [NOT ]MEMBER [OF ] collection_valued_path_expression
private Sequence colMemExp;
protected Parser collectionMemberExpression() {
if(colMemExp == null) {
colMemExp = new Sequence();
- colMemExp.add(singleValuedPathExpression());
+
+ Alternation varOrParam = new Alternation();
+ varOrParam.add(singleValuedNavigation());
+ varOrParam.add(identificationVariable());
+ //varOrParam.add(inputParameter());
+
+ colMemExp.add(varOrParam);
colMemExp.add(new Optional(new Literal(NOT)));
colMemExp.add(new Literal(MEMBER).discard());
colMemExp.add(new Optional(new Literal(OF).discard()));
@@ -517,8 +525,19 @@
compareSymbol = ;
compareFromPath = a.pop().toString();
}
+
+ String comparison;
+ if(?.equals(compareFromPath)) {
+ comparison = target.getEntityWherePathToParameter(
+ compareFromPath,
+ compareSymbol);
+ } else {
+ comparison = target.getEntityWherePathToPath(
+ compareFromPath,
+ compareSymbol,
+ compareTo);
+ }
- String comparison = target.getEntityWherePathToPath(compareFromPath,
compareSymbol, compareTo);
if(comparison == null) {
a.setInvalid();
} else {
@@ -775,6 +794,7 @@
return entBeanVal;
}
+ // CHANGED in FD
// entity_bean_expression ::= entity_bean_value | input_parameter
private Alternation entBeanExp;
protected Parser entityBeanExpression() {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty + JBoss getting started
You haven't done anything wrong. Until you deploy something, you won't find any apps running. Standalone Jetty ships with some demo apps statically configured - but this was confusing for JBoss/Jetty users who don't want to know about Jetty's static config file. They just want to deploy WebApps. Having something already statically deployed at '/' was not a good idea. Jules Jozsa Kristof wrote: Hi, probably that's the most FAQ question around, but I checked both the list archive and the forum (honestly!), and couldn't find any answer. I've got the latest JBoss+Jetty package (JBoss-2.4.3_Jetty-3.1.3-1.zip) from sourceforge, unpacked, chmod-ed, ran ./run.sh, and the whole started up successfully; however at http://localhost:8080, or at any url based on that (eg. /jetty or /jboss) all I get is a 404 page from Jetty. If I run Jetty standalone, (starting with 'jetty.sh start'), I've got a valid response and jetty serves the pages correctly. Now, as I've got it out of the box, I guess it should be some integration problem. Please give me an advice what I've did wrong.. My setup: IBM JDK 1.3 on debian linux (sid), environment variables (JAVA_HOME, JBOSS_DIST, JETTY_HOME) correctly set. Thanks in advance, Christopher ps. in the included README file Jules wrote that's the correct place to report/ask questions about JBoss and Jetty integration, I hope I wasn't horribly offtopic :) -- .Digital.Yearning.for.Networked.Assassination.and.Xenocide ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyTextMessage.java
User: weave
Date: 01/11/02 15:06:47
Modified:src/main/org/jboss/mq SpyTextMessage.java
Log:
Modified the readExternl() method to check the number of available
chunks. If there is only one chuck available then the initial capacity
of the StringBuffer is set to the number of available bytes.
This was necessary to avoid small messages from allocating large buffers.
In addition when testing with the IBM JDK the toString() method of
the StringBuffer class appeared to implement a copy-on-write char[]
sharing. This meant that if a large buffer was allocate it would not
be reduced to the message size since the StringBuffer was not modified
after the toString() call.
I'm still concerned that if the last chunk is realitively small then
there may be a fair amount of wasted space. This would become a smaller
precent as the number of chunks grow.
Revision ChangesPath
1.5 +5 -2 jbossmq/src/main/org/jboss/mq/SpyTextMessage.java
Index: SpyTextMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTextMessage.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyTextMessage.java 2001/10/28 04:07:34 1.4
+++ SpyTextMessage.java 2001/11/02 23:06:46 1.5
@@ -18,7 +18,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class SpyTextMessage
extends SpyMessage
@@ -73,7 +73,10 @@
// a StringBuffer that can hold all chunks, read the chunks
// into the buffer and set 'content' accordingly
int chunksToRead = in.readInt();
- StringBuffer sb = new StringBuffer(chunkSize * chunksToRead);
+ int bufferSize = chunkSize * chunksToRead;
+ if(chunksToRead = 1)
+bufferSize = Math.min(in.available(), bufferSize);
+ StringBuffer sb = new StringBuffer(bufferSize);
for (int i = 0; i chunksToRead; i++) {
sb.append( in.readUTF() );
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ JDBC PersistenceManager
Hi, Hiram, The technique you mentioned should generally works for most MBeans. But for ConnectionFactoryLoader, it's a little different. The org.jboss.resource.ConnectionFactoryLoader uses some kind of a two step initialization. The connection specified in your XML file is created and bound to JNDI only if the jboss-jdbc.rar is fully deployed. The init logic in ConnectionFactoryLoader looks like this: initService: - register itself as a deployment notification listener for the resource adapter (jboss-jdbc.rar) [it's a little bit more abstract that this, but you get the idea] startService: - if RARDeployer is present (it should because that's an explicit depends tag in the xml file), ask RARDeployer if jboss-jdbc.rar has been deployed. - if YES, continue to load the connection factory and perform all necessary initialization including JNDI name registration. - if NO, wait until it is notified (recall initService). To our dependency checker (AutoDeployer), ConnectionFactoryLoader is already deployed even if it has not fully initialize its internal connection factory. So, the deploy process continues and a JNDI NameNotFoundException is thrown when jbossmq-service.xml is deployed. I have traced thru the initialization steps in: http://www.jboss.org/forums/thread.jsp?forum=51thread=3359 It looks similar to this in this particular case (in sequence) 1. deploy/lib/jboss-jdbc.rar (don't deploy... wait until RARDeployer is deployed) 2. deploy/j2eedeployment-service.xml (now RARDeployer is deployed) 3. deploy/postgres-service.xml (deploy ConnectionFactoryLoader but cannot initialize its internal connection factory) 4. deploy/jbossmq-service.xml (NameNotFoundException) 5. deploy/lib/jboss-jdbc.rar (now, the JDBC resource adapter is deployed, RARDeployer fires deployment notification event to ConnectionFactoryLoader's listener. The listener initializes the internal connection factory and performs JNDI registration but it's too late for jbossmq-service.xml) I think the problem can be fixed if we can re-visit jboss-jdbc.rar once the RARDeployer is ready. That is, moving Step 5 up to Step 3. This is my investigation so far. I cc jboss-development to see if someone has a better idea. :) And I don't know which (jboss-dev or spydermq) mailing list is more appropriate. Charles --- Hiram Chirino [EMAIL PROTECTED] wrote: The problem with JDBC is because the jboss-jdbc.rar is deployed AFTER jbossmq-service.xml. So, when the PersistenceManager starts up, it complains about NameNotBoundException (JNDI exception). To workaround this problem, you can first move jbossmq-service.xml out of the deploy directory. After JBoss successfully starts up, you put the file back into the deploy directory. The PersistenceManager should then be deployed properly. To solve that problem, you might want to look into adding the a depends tag to the jbossmq-service.xml file so that it waits for the JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=DefaultDS I think this will delay jbossmq deployment until the DefaultDS is deployed. It would be WAY cool if we could get the jbossmq JDBC PM to work with the Hypersonic SQL database that is included with the default JBoss dist. What do you think?? Regards, Hiram I am using PostgreSQL which uses some wierd settings for Blob. Obviously, the JDBC PersistenceManager is not ready for this... So I cannot test if the actual functionality of the PersistenceManager. Since there doesn't seem to be a real demand for PostgreSQL persistence on JMS, I will try to get another DB and try it out. Charles --- Hiram Chirino [EMAIL PROTECTED] wrote: Cool.. I assume you have sourceforge ID. Send it to me, I'll have Mark F. get you RW access to the CVS. I forgot what the dependency problem was with JDBC. Could you refresh me?? Regards, Hiram From: Charles Chan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 2 Nov 2001 08:26:21 -0800 (PST) Hi, Hiram, I think I have found a solution to the port scanning problem: http://www.jboss.org/forums/thread.jsp?forum=48thread=3269 Please take a look. As for the JDBC problem, can we assume that the MBean dependency will be handled by someone else? Charles __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp __ Do
[JBoss-dev] EJB 2.0?
Hi all, First off, I have to warn you that I am fairly new to EJB and JBoss. After developing an app under JBoss-2.4.3-Tomcat, I figured I would make a try at playing with Rabbit Hole. I got everything checked out (HEAD), compiled, and running. (A little bit more documentation on this would be useful, but that is a different story...) My EJB 1.1 app runs just fine under the new setup. But now I want to start using some EJB 2.0 features. (Specifically, the CMR stuff) Any attempts at providing my setup with EJB 2.0 beans produce lots of errors during deployment. So what gives? What do I have to do to make JBoss accept EJB 2.0 beans? If this simply isn't implemented yet, what EJB 2.0 features can I use and more importantly, how can I use them. TIA! -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-477656 ] Minor cleanups - Scope.java
Patches item #477656, was opened at 2001-11-02 14:01
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=477656group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Guillaume Boissiere (boissier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor cleanups - Scope.java
Initial Comment:
Adds some javadocs comments to this class and an
import to HashMap.
Enjoy!
-- Guillaume
diff -urN
jboss/src/main/org/jboss/deployment/scope/Scope.java
gb-jboss/src/main/org/jboss/deployment/scope/Scope.java
---
jboss/src/main/org/jboss/deployment/scope/Scope.java
Tue Sep 11 14:34:59 2001
+++ gb-
jboss/src/main/org/jboss/deployment/scope/Scope.java
Fri Nov 2 16:47:30 2001
@@ -7,10 +7,11 @@
package org.jboss.deployment.scope;
-import java.util.Set;
-import java.util.Map;
-import java.util.Iterator;
import java.net.URL;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
import org.jboss.logging.Logger;
@@ -28,26 +29,34 @@
public class Scope {
/** keeps a map of class loaders that participate
in this scope */
-final protected Map classLoaders=new
java.util.HashMap();
+final protected Map classLoaders = new HashMap();
/** keeps a hashtable of dependencies between the
classLoaders */
-final protected Map dependencies=new
java.util.HashMap();
+final protected Map dependencies = new HashMap();
/** keeps a hashtable of class appearances */
-final protected Map classLocations=new
java.util.HashMap();
+final protected Map classLocations = new HashMap
();
/** keeps a hashtable of resource appearances */
-final protected Map resourceLocations=new
java.util.HashMap();
+final protected Map resourceLocations = new
HashMap();
/** keeps a reference to a logger which which to
interact */
final protected Logger log;
-/** Creates new Scope */
+/** Creates new Scope
+ *
+ * @param log - The logger this new scope will
interact with.
+ */
public Scope(Logger log) {
this.log=log;
}
-/** registers a classloader in this scope */
+/**
+ * Registers a classloader in this scope.
+ *
+ * @param loader - The classloader to register.
+ * @return The newly registered classloader.
+ */
public ScopedURLClassLoader registerClassLoader
(ScopedURLClassLoader loader) {
// must synchronize not to collide with
deregistrations and
// dependency logging
@@ -56,9 +65,12 @@
}
}
-
-/** deRegisters a classloader in this scope
- * removes all cached data related to this
classloader
+/**
+ * Deregisters a classloader in this scope.
+ * Removes all cached data related to this
classloader.
+ *
+ * @param loader - The classloader to deregister.
+ * @return The newly deregistered classloader.
*/
public ScopedURLClassLoader deRegisterClassLoader
(ScopedURLClassLoader loader) {
// synchronized not to collide with
registrations
@@ -75,8 +87,12 @@
}
}
-/** helper method that will clear all entries
from a map
- * with a dedicated target value.
+/**
+ * Helper method that will clear all entries from
a map
+ * with a dedicated target value.
+ *
+ * @param map - The map we want to clear entries
from.
+ * @param value - The object we want to remove
from that map.
*/
protected void clearByValue(Map map, Object
value) {
Iterator values=map.values().iterator();
@@ -87,19 +103,28 @@
}
}
-/** returns the classLoaders that a particular
classLoader is
- * dependent on. Should be called after locking
classLoaders
+/**
+ * Returns the classLoaders that a particular
classLoader is
+ * dependent on. Should be called after locking
classLoaders.
+ *
+ * @param loader - The classloader we want to
find dependencies of.
+ * @return The set of classloaders this
classloader is dependent on.
*/
public Set getDependentClassLoaders
(ScopedURLClassLoader loader) {
Set result=(Set) dependencies.get(loader);
if(result==null)
-result=new java.util.HashSet();
+result=new HashSet();
return result;
}
-/** adds a dependency between two classloaders.
this can be called
- * from within application threads that require
resource loading.
- * Should be called after locking classLoaders
+/**
+ * Adds a dependency between two classloaders.
This can be called
+ * from within application threads that require
resource loading.
+ * Should be called after locking classLoaders.
+ *
+ * @param source - The classloader we are adding
dependency from.
+ * @param target - The classloader we are
Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
Interesting situation. I have on my machine a reimplementation of the depends mechanism that changes the RARDeployment sequence so it does not rely on the notifications noted here. However, it eliminates the separate init and start steps of mbean startup. The only place this is used is setting up the queues and durable subscriptions for jboss mq. I got the rolling logged pm working this new way but not file or jdbc and I kind of ran out of energy for this. Anyone want to help? david jencks On 2001.11.02 18:45:55 -0500 Charles Chan wrote: Hi, Hiram, The technique you mentioned should generally works for most MBeans. But for ConnectionFactoryLoader, it's a little different. The org.jboss.resource.ConnectionFactoryLoader uses some kind of a two step initialization. The connection specified in your XML file is created and bound to JNDI only if the jboss-jdbc.rar is fully deployed. The init logic in ConnectionFactoryLoader looks like this: initService: - register itself as a deployment notification listener for the resource adapter (jboss-jdbc.rar) [it's a little bit more abstract that this, but you get the idea] startService: - if RARDeployer is present (it should because that's an explicit depends tag in the xml file), ask RARDeployer if jboss-jdbc.rar has been deployed. - if YES, continue to load the connection factory and perform all necessary initialization including JNDI name registration. - if NO, wait until it is notified (recall initService). To our dependency checker (AutoDeployer), ConnectionFactoryLoader is already deployed even if it has not fully initialize its internal connection factory. So, the deploy process continues and a JNDI NameNotFoundException is thrown when jbossmq-service.xml is deployed. I have traced thru the initialization steps in: http://www.jboss.org/forums/thread.jsp?forum=51thread=3359 It looks similar to this in this particular case (in sequence) 1. deploy/lib/jboss-jdbc.rar (don't deploy... wait until RARDeployer is deployed) 2. deploy/j2eedeployment-service.xml (now RARDeployer is deployed) 3. deploy/postgres-service.xml (deploy ConnectionFactoryLoader but cannot initialize its internal connection factory) 4. deploy/jbossmq-service.xml (NameNotFoundException) 5. deploy/lib/jboss-jdbc.rar (now, the JDBC resource adapter is deployed, RARDeployer fires deployment notification event to ConnectionFactoryLoader's listener. The listener initializes the internal connection factory and performs JNDI registration but it's too late for jbossmq-service.xml) I think the problem can be fixed if we can re-visit jboss-jdbc.rar once the RARDeployer is ready. That is, moving Step 5 up to Step 3. This is my investigation so far. I cc jboss-development to see if someone has a better idea. :) And I don't know which (jboss-dev or spydermq) mailing list is more appropriate. Charles --- Hiram Chirino [EMAIL PROTECTED] wrote: The problem with JDBC is because the jboss-jdbc.rar is deployed AFTER jbossmq-service.xml. So, when the PersistenceManager starts up, it complains about NameNotBoundException (JNDI exception). To workaround this problem, you can first move jbossmq-service.xml out of the deploy directory. After JBoss successfully starts up, you put the file back into the deploy directory. The PersistenceManager should then be deployed properly. To solve that problem, you might want to look into adding the a depends tag to the jbossmq-service.xml file so that it waits for the JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=DefaultDS I think this will delay jbossmq deployment until the DefaultDS is deployed. It would be WAY cool if we could get the jbossmq JDBC PM to work with the Hypersonic SQL database that is included with the default JBoss dist. What do you think?? Regards, Hiram I am using PostgreSQL which uses some wierd settings for Blob. Obviously, the JDBC PersistenceManager is not ready for this... So I cannot test if the actual functionality of the PersistenceManager. Since there doesn't seem to be a real demand for PostgreSQL persistence on JMS, I will try to get another DB and try it out. Charles --- Hiram Chirino [EMAIL PROTECTED] wrote: Cool.. I assume you have sourceforge ID. Send it to me, I'll have Mark F. get you RW access to the CVS. I forgot what the dependency problem was with JDBC. Could you refresh me?? Regards, Hiram From: Charles Chan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 2 Nov 2001 08:26:21 -0800 (PST) Hi, Hiram, I think I have found a solution to the port scanning problem: http://www.jboss.org/forums/thread.jsp?forum=48thread=3269 Please take a look. As for the JDBC problem, can we assume
RE: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions????
While I agree that this is not a bug, and it should therefore be closed, I do agree with the guy who gave that bug. It is true that buildmagic is WAAY too complex for what it does and introduces an unnecessarily scary barrier to entry. I don't use the 1000 configuration files that come with it, never will. The only thing that is useful there is the capacity to build all the modules in a dependent way, that is good. The rest is useless. marcf PS: The deeper scare for me is that we were commenting with Scott that no-one has really come into the code lately, meaning no new blood in the last 2 month. That is not good and it corresponds to the introduction of buildmagic. It will need to be simplified A LOT or it will need to be replaced by something simpler. A un-necessarily complex build environment is the surest way to kill the development on JBoss. As a first step I don't think there should be ANY configuration file besides the xml build. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Friday, November 02, 2001 6:55 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions | | |Bugs item #450615, was opened at 2001-08-13 14:11 |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |group_id=22866 | |Category: None |Group: None |Status: Closed |Resolution: Rejected |Priority: 5 |Submitted By: Nobody/Anonymous (nobody) |Assigned to: Andreas Schaefer (schaefera) |Summary: Build instructions | |Initial Comment: |There are no build instructions anywhere. | |Simply downloading the cvs projects listed, and running a build.sh |doesn't do the trick. | |Also, not all the projects are listed. Looking in the developer |archive suggested a project called |jboss-all, which did put some more stuff on disk, but nothing that |made the build run. | |Firing off ant on some build.xml files also doesn't go very far. | |So, what are the secret steps to build jboss from source? | |Thanks! | |-- | |Comment By: Andreas Schaefer (schaefera) |Date: 2001-10-29 20:21 | |Message: |Logged In: YES |user_id=70434 | |Build current CVS HEAD for Rabbit Hole: |- checkout CVS module jboss-all |- go to jboss-all/build |- start either build.sh or build.bat | |Run then the builded JBoss instance: |- go to jboss-all/build/output/jboss*/bin where * means |the current version |- start either run.sh or run.bat | |Further options (inclusive running the test suite): |- go to jboss-all/build |- start either build.sh help or build.bat help but do |not mix this up with build -help |- go from there | |Building components: |- go to the component you want like jboss-all/server |- start either build.sh or build.bat from there |- the compiled code can be found under jboss- |all/server/output | |Andy | |-- | |Comment By: Christian Biasuzzi (bchristian) |Date: 2001-08-22 03:26 | |Message: |Logged In: YES |user_id=220544 | |I checked-out the whole list of projects listed, including | build, thirdparty, tools |I renamed folder names according to a config.xml as follows: | jboss - server | jnp - naming | jbossmp - messaging | jbosscx - connector | jboss-j2ee - j2ee | contrib - plugins | jbosspool - pool | jbosssx - security | jbossmx - cluster |I copied build/jboss content to build/ and launched build | script from there. The former dist folder is now in | build/output | |it worked from me! | | | |-- | |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |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] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
User: dbudworth
Date: 01/11/02 18:07:41
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
added more descriptive NoSuchMethodException throw. Default version didn't
specify what class or what method, requiring users to look in the jboss source
to find out what method was missing. The method name createMethodCache()
sounds more like create a method cache, and not create a create method cache
So the stack trace was pretty much useless.
Revision ChangesPath
1.33 +8 -3 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- CMPPersistenceManager.java2001/10/09 00:59:39 1.32
+++ CMPPersistenceManager.java2001/11/03 02:07:41 1.33
@@ -53,7 +53,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
-* @version $Revision: 1.32 $
+* @version $Revision: 1.33 $
*
* Revisions:
* 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
@@ -156,8 +156,13 @@
{
if (methods[i].getName().equals(create))
{
-createMethods.put(methods[i], con.getBeanClass().getMethod(ejbCreate,
methods[i].getParameterTypes()));
-postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+ try{
+ createMethods.put(methods[i],
con.getBeanClass().getMethod(ejbCreate, methods[i].getParameterTypes()));
+ postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+ }
+ catch (NoSuchMethodException nsme){
+ throw new NoSuchMethodException(Can't find
ejb[Post]Create in +con.getBeanClass().getName());
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Please follow the coding standards when submitting changes. They
are listed here: http://www.jboss.org/developers/guidelines.jsp
Your checkin is using tabs instead of spaces and is not aligning
braces consistent with the rest of the code.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: David Budworth [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 6:07 PM
Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins
CMPPersistenceManager.java
User: dbudworth
Date: 01/11/02 18:07:41
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
added more descriptive NoSuchMethodException throw. Default version
didn't
specify what class or what method, requiring users to look in the jboss
source
to find out what method was missing. The method name
createMethodCache()
sounds more like create a method cache, and not create a create
method cache
So the stack trace was pretty much useless.
Revision ChangesPath
1.33 +8 -3
jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.ja
va,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- CMPPersistenceManager.java 2001/10/09 00:59:39 1.32
+++ CMPPersistenceManager.java 2001/11/03 02:07:41 1.33
@@ -53,7 +53,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas
Schaefer/a
-* @version $Revision: 1.32 $
+* @version $Revision: 1.33 $
*
* Revisions:
* 20010621 Bill Burke: removed loadEntities call because CMP
read-ahead is now
@@ -156,8 +156,13 @@
{
if (methods[i].getName().equals(create))
{
-createMethods.put(methods[i],
con.getBeanClass().getMethod(ejbCreate, methods[i].getParameterTypes()));
-postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate,
methods[i].getParameterTypes()));
+ try{
+ createMethods.put(methods[i],
con.getBeanClass().getMethod(ejbCreate, methods[i].getParameterTypes()));
+ postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate,
methods[i].getParameterTypes()));
+ }
+ catch (NoSuchMethodException nsme){
+ throw new NoSuchMethodException(Can't find ejb[Post]Create in
+con.getBeanClass().getName());
+ }
}
}
___
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/plugins CMPPersistenceManager.java
User: starksm
Date: 01/11/02 18:37:23
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
Cleanup formatting
Revision ChangesPath
1.34 +354 -259 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- CMPPersistenceManager.java2001/11/03 02:07:41 1.33
+++ CMPPersistenceManager.java2001/11/03 02:37:23 1.34
@@ -1,9 +1,9 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
package org.jboss.ejb.plugins;
import java.lang.reflect.Method;
@@ -42,27 +42,28 @@
import org.jboss.management.j2ee.TimeStatistic;
/**
-* The CMP Persistence Manager implements the semantics of the CMP
-* EJB 1.1 call back specification.
-*
-* This Manager works with a EntityPersistenceStore that takes care of the
-* physical storing of instances (JAWS, JDBC O/R, FILE, Object).
-*
-* @see related
-* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
-* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
-* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
-* @version $Revision: 1.33 $
-*
-* Revisions:
-* 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
-* done directly by the finder.
-* 20010709 Andreas Schaefer: added statistics gathering
-*
-*/
+ * The CMP Persistence Manager implements the semantics of the CMP
+ * EJB 1.1 call back specification.
+ *
+ * This Manager works with a EntityPersistenceStore that takes care of the
+ * physical storing of instances (JAWS, JDBC O/R, FILE, Object).
+ *
+ * @see related
+ * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
+ * @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
+ * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
+ * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
+ * @version $Revision: 1.34 $
+ *
+ * Revisions:
+ * 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
+ * done directly by the finder.
+ * 20010709 Andreas Schaefer: added statistics gathering
+ *
+ */
public class CMPPersistenceManager
- implements EntityPersistenceManager {
+ implements EntityPersistenceManager
+{
// Constants -
// Attributes
@@ -89,39 +90,43 @@
private TimeStatistic mStore = new TimeStatistic( Store, ms, Load Time );
// Static
-
-// Constructors --
-
-// Public
- public void setContainer(Container c) {
+
+ // Constructors --
+
+ // Public
+ public void setContainer(Container c)
+ {
con = (EntityContainer)c;
- if (store != null) store.setContainer(c);
+ if (store != null)
+ store.setContainer(c);
}
- /**
- * Gets the entity persistence store.
- */
- public EntityPersistenceStore getPersistenceStore() {
- return store;
- }
+ /**
+* Gets the entity persistence store.
+*/
+ public EntityPersistenceStore getPersistenceStore()
+ {
+ return store;
+ }
- public void setPersistenceStore(EntityPersistenceStore store) {
+ public void setPersistenceStore(EntityPersistenceStore store)
+ {
this.store= store;
-
+
//Give it the container
if (con!= null) store.setContainer(con);
}
public void init()
- throws Exception {
-
+ throws Exception
+ {
// The common EJB methods
ejbLoad = EntityBean.class.getMethod(ejbLoad, new Class[0]);
ejbStore = EntityBean.class.getMethod(ejbStore, new Class[0]);
ejbActivate = EntityBean.class.getMethod(ejbActivate, new Class[0]);
ejbPassivate = EntityBean.class.getMethod(ejbPassivate, new Class[0]);
ejbRemove = EntityBean.class.getMethod(ejbRemove, new Class[0]);
-
+
if (con.getHomeClass() != null)
{
Method[] methods =
[JBoss-dev] OBJECT_NAME rules
Perusing through the code, I saw the following variations for the service
names of MBeans in JBoss:
- no prefix, i.e :service=Mail
- EJB prefix, i.e EJB:service=
- JBOSS-SYSTEM prefix i.e JBOSS-SYSTEM:service=Info
- J2EE prefix i.e J2EE:service=J2eeDeployer
Are there any specific rules for the naming? If so, what are they?
Also I noticed that a couple of the MBeans had the OBJECT_NAME variable not
declared as public static final. Simple patch below.
-- Guillaume
diff -urN jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
--- jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Wed Aug 29
18:52:05 2001
+++ gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Fri Nov 2
21:39:32 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
--- jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Wed Aug 29
23:10:02 2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Fri Nov 2
21:43:49 2001
@@ -25,7 +25,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = :service=ContainerFactory;
+ public static final String OBJECT_NAME = :service=ContainerFactory;
/**
* Returns the applications deployed by the container factory
diff -urN jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
gb-jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
--- jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java Wed
Aug 29 23:10:54 2001
+++ gb-jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
Fri Nov 2 21:45:48 2001
@@ -31,7 +31,7 @@
extends ServiceMBean
{
/** The default MBean object name. */
- String OBJECT_NAME = :service=ServerSessionPoolMBean;
+ public static final String OBJECT_NAME =
:service=ServerSessionPoolLoader;
/**
* Set the pool name.
diff -urN jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java
gb-jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java
--- jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java Sat Oct 20
00:24:23 2001
+++ gb-jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java Fri Nov 2
21:47:42 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/system/InfoMBean.java
gb-jboss/src/main/org/jboss/system/InfoMBean.java
--- jboss/src/main/org/jboss/system/InfoMBean.java Fri Sep 7 20:53:56 2001
+++ gb-jboss/src/main/org/jboss/system/InfoMBean.java Fri Nov 2 21:49:25
2001
@@ -17,7 +17,7 @@
*/
public interface InfoMBean
{
- String OBJECT_NAME = JBOSS-SYSTEM:service=Info;
+ public static final String OBJECT_NAME = JBOSS-SYSTEM:service=Info;
String listMemoryUsage();
String listSystemInfo();
diff -urN jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java
gb-jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java
--- jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java Fri Sep 7
20:53:57 2001
+++ gb-jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java Fri Nov 2
21:49:26 2001
@@ -22,7 +22,7 @@
*/
public interface ServiceLibrariesMBean
{
- String OBJECT_NAME = JBOSS-SYSTEM:service=Libraries;
+ public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=Libraries;
// The ServicesLibraries MBean should expose soft information like
// the dependencies graph
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 140 Successful tests: 129 Errors:5 Failures: 6 [time of test: 3 November 2001 3:18 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-6] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] OBJECT_NAME rules
Hi
Your are right but Object Names rules are:
Domain Name:[key=value],...
Right now JBoss does not use the Object Name capabilities fully
one part you can see this is in the J2eeDeployer and WebDeployer.
There we could create the WebDeployer service like this:
JBOSS-SYSTEM:service=deployer,type=web,vendor=jetty
This would enable use to skip to specify the WebDeployer name
in the J2eeDeployer but instead the J2eeDeployer could search
for a service with:
JBOSS-SYSTEM:service=deployer,typ=web
and whatever vendor the web deployer service provides does
not matter.
The Object names with no Domain Name is the worst because in
JMX-RI is a big bug not able to find this MBean even it does allow
the MBean to be registered with its name.
Have fun - Andy
- Original Message -
From: Guillaume Boissiere [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 7:07 PM
Subject: [JBoss-dev] OBJECT_NAME rules
Perusing through the code, I saw the following variations for the service
names of MBeans in JBoss:
- no prefix, i.e :service=Mail
- EJB prefix, i.e EJB:service=
- JBOSS-SYSTEM prefix i.e JBOSS-SYSTEM:service=Info
- J2EE prefix i.e J2EE:service=J2eeDeployer
Are there any specific rules for the naming? If so, what are they?
Also I noticed that a couple of the MBeans had the OBJECT_NAME variable
not
declared as public static final. Simple patch below.
-- Guillaume
diff -urN jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
--- jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Wed Aug 29
18:52:05 2001
+++ gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Fri Nov
2
21:39:32 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
--- jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Wed Aug 29
23:10:02 2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Fri Nov 2
21:43:49 2001
@@ -25,7 +25,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = :service=ContainerFactory;
+ public static final String OBJECT_NAME = :service=ContainerFactory;
/**
* Returns the applications deployed by the container factory
diff -urN
jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
gb-jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
--- jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java Wed
Aug 29 23:10:54 2001
+++ gb-jboss/src/main/org/jboss/jms/asf/ServerSessionPoolLoaderMBean.java
Fri Nov 2 21:45:48 2001
@@ -31,7 +31,7 @@
extends ServiceMBean
{
/** The default MBean object name. */
- String OBJECT_NAME = :service=ServerSessionPoolMBean;
+ public static final String OBJECT_NAME =
:service=ServerSessionPoolLoader;
/**
* Set the pool name.
diff -urN jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java
gb-jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java
--- jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java Sat Oct 20
00:24:23 2001
+++ gb-jboss/src/main/org/jboss/system/FarmAutoDeployerMBean.java Fri Nov
2
21:47:42 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/system/InfoMBean.java
gb-jboss/src/main/org/jboss/system/InfoMBean.java
--- jboss/src/main/org/jboss/system/InfoMBean.java Fri Sep 7 20:53:56
2001
+++ gb-jboss/src/main/org/jboss/system/InfoMBean.java Fri Nov 2 21:49:25
2001
@@ -17,7 +17,7 @@
*/
public interface InfoMBean
{
- String OBJECT_NAME = JBOSS-SYSTEM:service=Info;
+ public static final String OBJECT_NAME = JBOSS-SYSTEM:service=Info;
String listMemoryUsage();
String listSystemInfo();
diff -urN jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java
gb-jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java
--- jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java Fri Sep 7
20:53:57 2001
+++ gb-jboss/src/main/org/jboss/system/ServiceLibrariesMBean.java Fri Nov
2
21:49:26 2001
@@ -22,7 +22,7 @@
*/
public interface ServiceLibrariesMBean
{
- String OBJECT_NAME = JBOSS-SYSTEM:service=Libraries;
+ public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=Libraries;
// The ServicesLibraries MBean should expose soft information like
// the dependencies graph
___
Jboss-development mailing
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 140 Successful tests: 131 Errors:4 Failures: 5 [time of test: 3 November 2001 4:8 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-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-6] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions????
Marc, while it is likely that buildmagic is more complicated than necessary, it does not require any external config files. I have found some of the local properties files (that you have to set up if you want to use them) very useful for things like specifying the number of iterations on stress tests. I think the big problem is people trying to check 2.4 out using jboss-all and 3.0 out without using jboss-all. I can't find any instructions on building 2.4, and the ones for 3 are hard to find. I think the semi-unfinished state of 3 may be a more likely barrier to new work. david jencks On 2001.11.02 20:36:23 -0500 marc fleury wrote: While I agree that this is not a bug, and it should therefore be closed, I do agree with the guy who gave that bug. It is true that buildmagic is WAAY too complex for what it does and introduces an unnecessarily scary barrier to entry. I don't use the 1000 configuration files that come with it, never will. The only thing that is useful there is the capacity to build all the modules in a dependent way, that is good. The rest is useless. marcf PS: The deeper scare for me is that we were commenting with Scott that no-one has really come into the code lately, meaning no new blood in the last 2 month. That is not good and it corresponds to the introduction of buildmagic. It will need to be simplified A LOT or it will need to be replaced by something simpler. A un-necessarily complex build environment is the surest way to kill the development on JBoss. As a first step I don't think there should be ANY configuration file besides the xml build. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Friday, November 02, 2001 6:55 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions | | |Bugs item #450615, was opened at 2001-08-13 14:11 |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |group_id=22866 | |Category: None |Group: None |Status: Closed |Resolution: Rejected |Priority: 5 |Submitted By: Nobody/Anonymous (nobody) |Assigned to: Andreas Schaefer (schaefera) |Summary: Build instructions | |Initial Comment: |There are no build instructions anywhere. | |Simply downloading the cvs projects listed, and running a build.sh |doesn't do the trick. | |Also, not all the projects are listed. Looking in the developer |archive suggested a project called |jboss-all, which did put some more stuff on disk, but nothing that |made the build run. | |Firing off ant on some build.xml files also doesn't go very far. | |So, what are the secret steps to build jboss from source? | |Thanks! | |-- | |Comment By: Andreas Schaefer (schaefera) |Date: 2001-10-29 20:21 | |Message: |Logged In: YES |user_id=70434 | |Build current CVS HEAD for Rabbit Hole: |- checkout CVS module jboss-all |- go to jboss-all/build |- start either build.sh or build.bat | |Run then the builded JBoss instance: |- go to jboss-all/build/output/jboss*/bin where * means |the current version |- start either run.sh or run.bat | |Further options (inclusive running the test suite): |- go to jboss-all/build |- start either build.sh help or build.bat help but do |not mix this up with build -help |- go from there | |Building components: |- go to the component you want like jboss-all/server |- start either build.sh or build.bat from there |- the compiled code can be found under jboss- |all/server/output | |Andy | |-- | |Comment By: Christian Biasuzzi (bchristian) |Date: 2001-08-22 03:26 | |Message: |Logged In: YES |user_id=220544 | |I checked-out the whole list of projects listed, including | build, thirdparty, tools |I renamed folder names according to a config.xml as follows: | jboss - server | jnp - naming | jbossmp - messaging | jbosscx - connector | jboss-j2ee - j2ee | contrib - plugins | jbosspool - pool | jbosssx - security | jbossmx - cluster |I copied build/jboss content to build/ and launched build | script from there. The former dist folder is now in | build/output | |it worked from me! | | | |-- | |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |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
Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
Well, don't confuse the rar and the connectionfactory. What I have on my machine, using the mbean references, is like this: a rar gets a RARDeployment mbean, which among other things lets you see the default properties and classes easily, but mostly allows you to depend on it. The ConnectionFactoryLoader has mbean references (dependencies) to the required RAR(Deployment) and the ConnectionManager(Factory) it uses. So, it will deploy as soon as the exact things it needs are present. No need for the artificial reference to RARDeployer. Do you think we should follow weblogic's lead and allow and encourage including a jboss-service.xml in a rar to allow configuring ConnectionFactory(Loaders) within the rar? It's certainly easy enough, but I have my doubts about the wisdom. I definitely want to preserve the ability to have ConnectionFactoryLoader configurations outside the rar. david jencks On 2001.11.02 20:45:09 -0500 Scott M Stark wrote: I'm not particularly keen on how we couple the deployment properties of a RAR to an MBean configuration AND a JMX notification. This makes the configuration for a RAR inconsistent with any other J2EE component deployment where this information is specified via a JBoss specific descriptor to build a self contained deployment unit. The configuration is also more convoluted as you have to specifiy the name of the RAR deployer MBean so that notifications are received. This really makes no sense to someone who just happens to have a RAR to deploy and hasn't been dragged through the JMX bus school of religion. I definitely want to change this for 3.0 and so I'll pickup what you have and finish the deployment layer for 3.0 in a couple of weeks when I finish the book. I'm not sure if I want to introduce such a change for the handling of RARs into the 2.4 branch. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 02, 2001 4:43 PM Subject: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager Interesting situation. I have on my machine a reimplementation of the depends mechanism that changes the RARDeployment sequence so it does not rely on the notifications noted here. However, it eliminates the separate init and start steps of mbean startup. The only place this is used is setting up the queues and durable subscriptions for jboss mq. I got the rolling logged pm working this new way but not file or jdbc and I kind of ran out of energy for this. Anyone want to help? david jencks On 2001.11.02 18:45:55 -0500 Charles Chan wrote: Hi, Hiram, The technique you mentioned should generally works for most MBeans. But for ConnectionFactoryLoader, it's a little different. The org.jboss.resource.ConnectionFactoryLoader uses some kind of a two step initialization. The connection specified in your XML file is created and bound to JNDI only if the jboss-jdbc.rar is fully deployed. The init logic in ConnectionFactoryLoader looks like this: initService: - register itself as a deployment notification listener for the resource adapter (jboss-jdbc.rar) [it's a little bit more abstract that this, but you get the idea] startService: - if RARDeployer is present (it should because that's an explicit depends tag in the xml file), ask RARDeployer if jboss-jdbc.rar has been deployed. - if YES, continue to load the connection factory and perform all necessary initialization including JNDI name registration. - if NO, wait until it is notified (recall initService). To our dependency checker (AutoDeployer), ConnectionFactoryLoader is already deployed even if it has not fully initialize its internal connection factory. So, the deploy process continues and a JNDI NameNotFoundException is thrown when jbossmq-service.xml is deployed. I have traced thru the initialization steps in: http://www.jboss.org/forums/thread.jsp?forum=51thread=3359 It looks similar to this in this particular case (in sequence) 1. deploy/lib/jboss-jdbc.rar (don't deploy... wait until RARDeployer is deployed) 2. deploy/j2eedeployment-service.xml (now RARDeployer is deployed) 3. deploy/postgres-service.xml (deploy ConnectionFactoryLoader but cannot initialize its internal connection factory) 4. deploy/jbossmq-service.xml (NameNotFoundException) 5. deploy/lib/jboss-jdbc.rar (now, the JDBC resource adapter is deployed, RARDeployer fires deployment notification event to ConnectionFactoryLoader's listener. The listener initializes the internal connection factory and performs JNDI registration but it's too late for jbossmq-service.xml) I think the problem can be fixed if we can re-visit jboss-jdbc.rar once the RARDeployer
RE: [JBoss-dev] OBJECT_NAME rules
Andy,
Thanks for your quick response! Here is an updated patch that makes
the naming more in line with the spec, by adding JBOSS-SYSTEM where
it is missing in the code.
Should make it easier to use the full Object Name capabilities in
the future.
Comments welcome,
-- Guillaume
diff -urN
jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
gb-jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
--- jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
Fri Aug 3 13:15:42 2001
+++ gb-jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
Fri Nov 2 23:03:50 2001
@@ -19,7 +19,7 @@
public interface ConfigurationServiceMBean
{
/** The default object name. */
-public static final String OBJECT_NAME = :service=Configuration;
+public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=Configuration;
/**
* Get the attribute value auto-trim flag.
diff -urN jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
--- jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Wed Aug 29
18:52:05 2001
+++ gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Fri Nov 2
21:39:32 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/deployment/J2eeDeployer.java
gb-jboss/src/main/org/jboss/deployment/J2eeDeployer.java
--- jboss/src/main/org/jboss/deployment/J2eeDeployer.java Mon Oct 8
03:03:49 2001
+++ gb-jboss/src/main/org/jboss/deployment/J2eeDeployer.javaFri Nov 2
23:06:23 2001
@@ -81,11 +81,11 @@
// Constants -
public File DEPLOYMENT_DIR = null;///home/deployment; // default?
MUST BE ABSOLUTE PATH!!!
public static String CONFIG = deployment.cfg;
-final public static String DEFAULT_NAME=Default;
-final public static String
DEFAULT_JAR_DEPLOYER_NAME=EJB:service=ContainerFactory;
-final public static String
DEFAULT_WAR_DEPLOYER_NAME=:service=EmbeddedTomcat;
-final public static String
DEFAULT_RAR_DEPLOYER_NAME=:service=RarDeployer;
-final public static String
DEFAULT_JAVA_DEPLOYER_NAME=:service=JavaDeployer;
+public static final String DEFAULT_NAME=Default;
+public static final String
DEFAULT_JAR_DEPLOYER_NAME=EJB:service=ContainerFactory;
+public static final String
DEFAULT_WAR_DEPLOYER_NAME=EJB:service=EmbeddedTomcat;
+public static final String
DEFAULT_RAR_DEPLOYER_NAME=EJB:service=RarDeployer;
+public static final String
DEFAULT_JAVA_DEPLOYER_NAME=EJB:service=JavaDeployer;
public static final int EASY = 0;
public static final int RESTRICTIVE = 1;
diff -urN jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
--- jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Wed Aug 29
23:10:02 2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Fri Nov 2
23:07:46 2001
@@ -25,7 +25,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = :service=ContainerFactory;
+ public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=ContainerFactory;
/**
* Returns the applications deployed by the container factory
diff -urN jboss/src/main/org/jboss/ejb/ContainerRelection.java
gb-jboss/src/main/org/jboss/ejb/ContainerRelection.java
--- jboss/src/main/org/jboss/ejb/ContainerRelection.javaFri Nov 2 15:41:40
2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerRelection.java Fri Nov 2
23:09:09 2001
@@ -23,7 +23,7 @@
*/
public class ContainerRelection extends ServiceMBeanSupport implements
ContainerRelectionMBean
{
- /** Lookup the mbean located under the object name
:service=Container,jndiName=jndiName
+ /** Lookup the mbean located under the object name
JBOSS-SYSTEM:service=Container,jndiName=jndiName
and invoke the getHome and getRemote interfaces and dump the methods
for each
in an html pre block.
*/
@@ -34,7 +34,7 @@
try
{
buffer.append(pre);
- ObjectName containerName = new
ObjectName(:service=Container,jndiName=+jndiName);
+ ObjectName containerName = new
ObjectName(JBOSS-SYSTEM:service=Container,jndiName=+jndiName);
Class homeClass = (Class) server.invoke(containerName, getHome,
null, null);
buffer.append(\nHome class = +homeClass);
buffer.append(\nClassLoader: +homeClass.getClassLoader());
diff -urN jboss/src/main/org/jboss/ejb/ContainerRelectionMBean.java
gb-jboss/src/main/org/jboss/ejb/ContainerRelectionMBean.java
--- jboss/src/main/org/jboss/ejb/ContainerRelectionMBean.java Mon Aug 13
23:31:34 2001
+++
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 130 Successful tests: 121 Errors:4 Failures: 5 [time of test: 3 November 2001 5:28 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-6] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] OBJECT_NAME rules
Hi
I think to add everywhere a DomainName to the ObjectNames of the MBeans
is a great idea. But please keep in mind that some MBean overwrite the given
ObjectName to enforce a particulare name (see preRegister()) methods.
On the other side not all MBeans should be added to JBOSS-SYSTEM because
the domain name is used to segment the JMX namespace. JBOSS-SYSTEM is
the default domain name meaning that a client does not have to know the
default
domain name to search for these MBeans. But when you want to create a
special
segement where it is necessary for a client to know the name and a grouping
is
appropriate then I think it is better to use a separate Domain Name.
Have fun - Andy
- Original Message -
From: Guillaume Boissiere [EMAIL PROTECTED]
To: Andreas Schaefer [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, November 02, 2001 8:31 PM
Subject: RE: [JBoss-dev] OBJECT_NAME rules
Andy,
Thanks for your quick response! Here is an updated patch that makes
the naming more in line with the spec, by adding JBOSS-SYSTEM where
it is missing in the code.
Should make it easier to use the full Object Name capabilities in
the future.
Comments welcome,
-- Guillaume
diff -urN
jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
gb-jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
--- jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
Fri Aug 3 13:15:42 2001
+++
gb-jboss/src/main/org/jboss/configuration/ConfigurationServiceMBean.java
Fri Nov 2 23:03:50 2001
@@ -19,7 +19,7 @@
public interface ConfigurationServiceMBean
{
/** The default object name. */
-public static final String OBJECT_NAME = :service=Configuration;
+public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=Configuration;
/**
* Get the attribute value auto-trim flag.
diff -urN jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java
--- jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Wed Aug 29
18:52:05 2001
+++ gb-jboss/src/main/org/jboss/deployment/AutoDeployerMBean.java Fri Nov
2
21:39:32 2001
@@ -22,7 +22,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = EJB:service=AutoDeployer;
+ public static final String OBJECT_NAME = EJB:service=AutoDeployer;
/**
* Set the list of urls to watch.
diff -urN jboss/src/main/org/jboss/deployment/J2eeDeployer.java
gb-jboss/src/main/org/jboss/deployment/J2eeDeployer.java
--- jboss/src/main/org/jboss/deployment/J2eeDeployer.java Mon Oct 8
03:03:49 2001
+++ gb-jboss/src/main/org/jboss/deployment/J2eeDeployer.java Fri Nov 2
23:06:23 2001
@@ -81,11 +81,11 @@
// Constants -
public File DEPLOYMENT_DIR = null;///home/deployment; // default?
MUST BE ABSOLUTE PATH!!!
public static String CONFIG = deployment.cfg;
-final public static String DEFAULT_NAME=Default;
-final public static String
DEFAULT_JAR_DEPLOYER_NAME=EJB:service=ContainerFactory;
-final public static String
DEFAULT_WAR_DEPLOYER_NAME=:service=EmbeddedTomcat;
-final public static String
DEFAULT_RAR_DEPLOYER_NAME=:service=RarDeployer;
-final public static String
DEFAULT_JAVA_DEPLOYER_NAME=:service=JavaDeployer;
+public static final String DEFAULT_NAME=Default;
+public static final String
DEFAULT_JAR_DEPLOYER_NAME=EJB:service=ContainerFactory;
+public static final String
DEFAULT_WAR_DEPLOYER_NAME=EJB:service=EmbeddedTomcat;
+public static final String
DEFAULT_RAR_DEPLOYER_NAME=EJB:service=RarDeployer;
+public static final String
DEFAULT_JAVA_DEPLOYER_NAME=EJB:service=JavaDeployer;
public static final int EASY = 0;
public static final int RESTRICTIVE = 1;
diff -urN jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java
--- jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Wed Aug 29
23:10:02 2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerFactoryMBean.java Fri Nov 2
23:07:46 2001
@@ -25,7 +25,7 @@
extends ServiceMBean
{
/** The default object name. */
- String OBJECT_NAME = :service=ContainerFactory;
+ public static final String OBJECT_NAME =
JBOSS-SYSTEM:service=ContainerFactory;
/**
* Returns the applications deployed by the container factory
diff -urN jboss/src/main/org/jboss/ejb/ContainerRelection.java
gb-jboss/src/main/org/jboss/ejb/ContainerRelection.java
--- jboss/src/main/org/jboss/ejb/ContainerRelection.java Fri Nov 2
15:41:40
2001
+++ gb-jboss/src/main/org/jboss/ejb/ContainerRelection.java Fri Nov 2
23:09:09 2001
@@ -23,7 +23,7 @@
*/
public class ContainerRelection extends ServiceMBeanSupport implements
ContainerRelectionMBean
{
- /** Lookup the mbean located under the object name
Re: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions????
Why do you don't write a HowTo for the JBoss 3 build ? Andy - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 02, 2001 8:15 PM Subject: Re: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions Marc, while it is likely that buildmagic is more complicated than necessary, it does not require any external config files. I have found some of the local properties files (that you have to set up if you want to use them) very useful for things like specifying the number of iterations on stress tests. I think the big problem is people trying to check 2.4 out using jboss-all and 3.0 out without using jboss-all. I can't find any instructions on building 2.4, and the ones for 3 are hard to find. I think the semi-unfinished state of 3 may be a more likely barrier to new work. david jencks On 2001.11.02 20:36:23 -0500 marc fleury wrote: While I agree that this is not a bug, and it should therefore be closed, I do agree with the guy who gave that bug. It is true that buildmagic is WAAY too complex for what it does and introduces an unnecessarily scary barrier to entry. I don't use the 1000 configuration files that come with it, never will. The only thing that is useful there is the capacity to build all the modules in a dependent way, that is good. The rest is useless. marcf PS: The deeper scare for me is that we were commenting with Scott that no-one has really come into the code lately, meaning no new blood in the last 2 month. That is not good and it corresponds to the introduction of buildmagic. It will need to be simplified A LOT or it will need to be replaced by something simpler. A un-necessarily complex build environment is the surest way to kill the development on JBoss. As a first step I don't think there should be ANY configuration file besides the xml build. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Friday, November 02, 2001 6:55 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [ jboss-Bugs-450615 ] Build instructions | | |Bugs item #450615, was opened at 2001-08-13 14:11 |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |group_id=22866 | |Category: None |Group: None |Status: Closed |Resolution: Rejected |Priority: 5 |Submitted By: Nobody/Anonymous (nobody) |Assigned to: Andreas Schaefer (schaefera) |Summary: Build instructions | |Initial Comment: |There are no build instructions anywhere. | |Simply downloading the cvs projects listed, and running a build.sh |doesn't do the trick. | |Also, not all the projects are listed. Looking in the developer |archive suggested a project called |jboss-all, which did put some more stuff on disk, but nothing that |made the build run. | |Firing off ant on some build.xml files also doesn't go very far. | |So, what are the secret steps to build jboss from source? | |Thanks! | |-- | |Comment By: Andreas Schaefer (schaefera) |Date: 2001-10-29 20:21 | |Message: |Logged In: YES |user_id=70434 | |Build current CVS HEAD for Rabbit Hole: |- checkout CVS module jboss-all |- go to jboss-all/build |- start either build.sh or build.bat | |Run then the builded JBoss instance: |- go to jboss-all/build/output/jboss*/bin where * means |the current version |- start either run.sh or run.bat | |Further options (inclusive running the test suite): |- go to jboss-all/build |- start either build.sh help or build.bat help but do |not mix this up with build -help |- go from there | |Building components: |- go to the component you want like jboss-all/server |- start either build.sh or build.bat from there |- the compiled code can be found under jboss- |all/server/output | |Andy | |-- | |Comment By: Christian Biasuzzi (bchristian) |Date: 2001-08-22 03:26 | |Message: |Logged In: YES |user_id=220544 | |I checked-out the whole list of projects listed, including | build, thirdparty, tools |I renamed folder names according to a config.xml as follows: | jboss - server | jnp - naming | jbossmp - messaging | jbosscx - connector | jboss-j2ee - j2ee | contrib - plugins | jbosspool - pool | jbosssx - security | jbossmx - cluster |I copied build/jboss content to build/ and launched build | script from there. The former dist folder is now in | build/output | |it worked from me! | | | |-- | |You can respond by visiting: |http://sourceforge.net/tracker/?func=detailatid=376685aid=450615; |group_id=22866 |
Re: [JBoss-dev] Question about durable subscription setup
This a user level question so I posted a response on the user forums on the jboss website: http://jboss.org/forums/thread.jsp?forum=48thread=3505 Regards, Hiram From: Brian Weaver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] Question about durable subscription setup Date: Thu, 1 Nov 2001 16:55:53 -0500 Hi All, I've been trying to come up to speed on JBoss, espicially the MQ part of JBoss. To that end I've actually downloaded the source from CVS, built it, attempted to configure it, and made RPMs to install it for testing. The main problem I'm having right now it a lack of documentation. I'm working from the HEAD of the CVS tree and I cannot seem to get queue persistance working for some reason. I've gotten JBossMQ running and passing messages for both a queue and two topics, however the queue connection should be setup with persistance. I'm not seening anything written to the file system for the queue in the db directory or any of its subdirectories. I started trying to figure out the format of the jbossmq-state.xml file, and as best I can figure it has the following tag hierarchy: StateManager | - User | |- Name |- Password |- Id - DurableSubscription | |- Name - TopicName From the manual that I've read at http://www.jboss.org/online-manual/HTML/ch08s07.html I'm left in the dark about just what the fields are and/or how their used. For example if I create a user with a password, how do I pass that information to JBossMQ when opening a connection to the MQ server. And I'm really clueless about the DurableSubscription and child fields. I could probably figuer it out an a week or two by going through the code, but I'd prefer to keep testing my application, while learning jboss instead of having to do a mental context switch to JBossMQ and/or search for another MQ server. In Short Help! Thanks Weave ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-459443 ] deexternalization problem
Bugs item #459443, was opened at 2001-09-07 00:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=459443group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: deexternalization problem
Initial Comment:
I cannot read externalized data back from database
using jboss2.4
Still, if I write into database using jboss-2.4.0-
tomcat-3.2.3 I can read back using jboss-2.2.2-tomcat-
3.2.2 without problems.
I'm using MS SQL server 7.0 with jdbc-odbc bridge
(from jdk1.3.1)
Table contains 2 fields:
id integer -- 32 bit
mydata image -- BLOB in other databases
MyBean is CMP Entity:
public class MyBean implements EntityBean {
public int id;
public MyDataMarshaller mydata;
...
}
id class is:
public class PKint implements java.io.Serializable {
public int id;
...
}
mydata class is:
public class MyDataMarshaller implements
java.io.Externalizable {
...
public void writeExternal( ObjectOutput out )throws
IOException{
out.write( 3 );
... }
public void readExternal ( ObjectInput in ) throws
IOException,
ClassNotFoundException{
int i = in.read();
... }
}
deployment is solely described in ejb-jar.xml
Writing the bean goes ok, but the read fails:
I read using findAll();
then I get iterator and first bean from iterator
and when I'm trying to get MyDataMarshaller from
MyBean the exception goes:
Note: I have read the [JAWS] Got a [B: '[B@5f75d8'
while looking for a com.mypackage.MyDataMarshaller
line in the log file too using JBoss_2.2.2-
tomcat_3.2.2 which works ok
[JAWS] findAll command executing: SELECT id FROM
MyTable
[MyTable] Activated bean MyTable with id = MyTablePK
[207726]
'MyTablePK[207726]' printed from toString()
[JAWS] Load command executing: SELECT
MyTable.id,MyTable.mydata FROM MyTable
WHERE id=?
[JAWS] Set parameter: idx=1, jdbcType=INTEGER,
value=207726
[JAWS] Got a [B: '[B@5f75d8' while looking for a
com.mypackage.MyDataMarshaller
[JAWS] Unable to read from ResultSet:
java.lang.reflect.InvocationTargetException
[JAWS] java.sql.SQLException: [Microsoft][ODBC SQL
Server Driver]Invalid
Descriptor Index
[JAWS] at sun.jdbc.odbc.JdbcOdbc.createSQLException
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbc.standardError
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbc.SQLGetDataInteger
(Unknown Source)
[JAWS] at
sun.jdbc.odbc.JdbcOdbcResultSet.getDataInteger(Unknown
Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbcResultSet.getInt
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbcResultSet.getObject
(Unknown Source)
[JAWS] at
org.jboss.pool.jdbc.ResultSetInPool.getObject
(ResultSetInPool.java:554)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultOb
ject(JDBCCommand.java
:405)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultOb
ject(JDBCCommand.java
:504)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.l
oadOneEntity(JDBCLoad
EntityCommand.java:219)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.h
andleResult(JDBCLoadE
ntityCommand.java:176)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCQueryCommand.execut
eStatementAndHandleRe
sult(JDBCQueryCommand.java:59)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute
(JDBCCommand.java:160
)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.e
xecute(JDBCLoadEntity
Command.java:147)
[JAWS] at
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadE
ntity(JAWSPersistence
Manager.java:156)
[JAWS] at
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity
(CMPPersistenceManager
.java:365)
[JAWS] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.
invoke(EntitySynchron
izationInterceptor.java:263)
[JAWS] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke
(EntityInstanceInterce
ptor.java:256)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext
(TxInterceptorCMT.java:133)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.
java:307)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:99)
[JAWS] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:12
8)
[JAWS] at
org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:195)
[JAWS] at org.jboss.ejb.EntityContainer.invoke
(EntityContainer.java:349)
[JAWS] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.
invoke(JRMPContainerI
nvoker.java:483)
[JAWS] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericPr
oxy.java:335)
[JAWS] at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invok
e(EntityProxy.java:13
3)
[JAWS] at $Proxy30.getMarshaller(Unknown Source)
[JAWS] at mypackage.MyEvent.onMessage(***.java:77)
[JAWS] at java.lang.reflect.Method.invoke(Native
Method)
[JAWS] at
org.jboss.ejb.MessageDrivenContainer$ContainerIntercept
or.invoke(MessageDriv
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 140 Successful tests: 131 Errors:4 Failures: 5 [time of test: 3 November 2001 6:27 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-6] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-459443 ] deexternalization problem
Bugs item #459443, was opened at 2001-09-07 00:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=459443group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: deexternalization problem
Initial Comment:
I cannot read externalized data back from database
using jboss2.4
Still, if I write into database using jboss-2.4.0-
tomcat-3.2.3 I can read back using jboss-2.2.2-tomcat-
3.2.2 without problems.
I'm using MS SQL server 7.0 with jdbc-odbc bridge
(from jdk1.3.1)
Table contains 2 fields:
id integer -- 32 bit
mydata image -- BLOB in other databases
MyBean is CMP Entity:
public class MyBean implements EntityBean {
public int id;
public MyDataMarshaller mydata;
...
}
id class is:
public class PKint implements java.io.Serializable {
public int id;
...
}
mydata class is:
public class MyDataMarshaller implements
java.io.Externalizable {
...
public void writeExternal( ObjectOutput out )throws
IOException{
out.write( 3 );
... }
public void readExternal ( ObjectInput in ) throws
IOException,
ClassNotFoundException{
int i = in.read();
... }
}
deployment is solely described in ejb-jar.xml
Writing the bean goes ok, but the read fails:
I read using findAll();
then I get iterator and first bean from iterator
and when I'm trying to get MyDataMarshaller from
MyBean the exception goes:
Note: I have read the [JAWS] Got a [B: '[B@5f75d8'
while looking for a com.mypackage.MyDataMarshaller
line in the log file too using JBoss_2.2.2-
tomcat_3.2.2 which works ok
[JAWS] findAll command executing: SELECT id FROM
MyTable
[MyTable] Activated bean MyTable with id = MyTablePK
[207726]
'MyTablePK[207726]' printed from toString()
[JAWS] Load command executing: SELECT
MyTable.id,MyTable.mydata FROM MyTable
WHERE id=?
[JAWS] Set parameter: idx=1, jdbcType=INTEGER,
value=207726
[JAWS] Got a [B: '[B@5f75d8' while looking for a
com.mypackage.MyDataMarshaller
[JAWS] Unable to read from ResultSet:
java.lang.reflect.InvocationTargetException
[JAWS] java.sql.SQLException: [Microsoft][ODBC SQL
Server Driver]Invalid
Descriptor Index
[JAWS] at sun.jdbc.odbc.JdbcOdbc.createSQLException
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbc.standardError
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbc.SQLGetDataInteger
(Unknown Source)
[JAWS] at
sun.jdbc.odbc.JdbcOdbcResultSet.getDataInteger(Unknown
Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbcResultSet.getInt
(Unknown Source)
[JAWS] at sun.jdbc.odbc.JdbcOdbcResultSet.getObject
(Unknown Source)
[JAWS] at
org.jboss.pool.jdbc.ResultSetInPool.getObject
(ResultSetInPool.java:554)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultOb
ject(JDBCCommand.java
:405)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultOb
ject(JDBCCommand.java
:504)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.l
oadOneEntity(JDBCLoad
EntityCommand.java:219)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.h
andleResult(JDBCLoadE
ntityCommand.java:176)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCQueryCommand.execut
eStatementAndHandleRe
sult(JDBCQueryCommand.java:59)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute
(JDBCCommand.java:160
)
[JAWS] at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.e
xecute(JDBCLoadEntity
Command.java:147)
[JAWS] at
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadE
ntity(JAWSPersistence
Manager.java:156)
[JAWS] at
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity
(CMPPersistenceManager
.java:365)
[JAWS] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.
invoke(EntitySynchron
izationInterceptor.java:263)
[JAWS] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke
(EntityInstanceInterce
ptor.java:256)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext
(TxInterceptorCMT.java:133)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.
java:307)
[JAWS] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:99)
[JAWS] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:12
8)
[JAWS] at
org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:195)
[JAWS] at org.jboss.ejb.EntityContainer.invoke
(EntityContainer.java:349)
[JAWS] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.
invoke(JRMPContainerI
nvoker.java:483)
[JAWS] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericPr
oxy.java:335)
[JAWS] at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invok
e(EntityProxy.java:13
3)
[JAWS] at $Proxy30.getMarshaller(Unknown Source)
[JAWS] at mypackage.MyEvent.onMessage(***.java:77)
[JAWS] at java.lang.reflect.Method.invoke(Native
Method)
[JAWS] at
org.jboss.ejb.MessageDrivenContainer$ContainerIntercept
or.invoke(MessageDriv
[JBoss-dev] [ jboss-Bugs-472046 ] NoSuchMethod-Error calling create
Bugs item #472046, was opened at 2001-10-17 05:24
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=472046group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: NoSuchMethod-Error calling create
Initial Comment:
If the business-interface of a stateless session bean
(I just checked ssbs) extends another interface that
itself extends another one, it seems as if no create
method is generated on deployment. =
NoSuchMethodError is thrown creating an instance of
the bean.
SMALL EXAMPLE:
public interface RemoteTest extends EJBObject, Test
{...}
public interface Test extends TestAccessOne
{...}public interface TestAccessOne
{
void foo() throws RemoteException;
}
public interface TestHome extends EJBHome
{
public RemoteTest create() throws CreateException,
RemoteException;
}
public class TestImpl implements Test, SessionBean
{
public void ejbCreate() {}
public void foo() throws RemoteException
{
System.out.println(foo);
}
}
Accessing the bean from a client as in:
Object objref = ctx.lookup(Test);
TestHome th = (TestHome)
javax.rmi.PortableRemoteObject.narrow(objref,
TestHome.class);
Test test = th.create();
throws the NoSuchMethodError. The important part of
the stack trace is
java.lang.NoSuchMethodError
RemoteTest $Proxy0.create()
I checked the bug against
-JBoss 2.2.2
-JBoss 2.4.3
both versions produced the same problem
JDK was 1.3.1_01
Moving the contents of interface TestAccessOne into
interface Test solves the technical problem!!
But the technical implementation should not interfere
the business decision to move the methods to another
interface.
Cheers,
Christian Elsen
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-02 15:09
Message:
Logged In: YES
user_id=70434
Both ways works for me but the ZIP file is the best. Just
use the Upload and Attach File boxes below !.
Andy
--
Comment By: Christian Elsen (celsen)
Date: 2001-10-31 06:13
Message:
Logged In: YES
user_id=364055
Do you want the descriptors and code as a comment? Or is it possible to attach a zip
file?
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-10-30 10:31
Message:
Logged In: YES
user_id=70434
I need some more informations about this. Please provide
the descriptors and maybe the code as well, would you ?
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-10-30 10:30
Message:
Logged In: YES
user_id=70434
I need some more informations about this. Please provide
the descriptors and maybe the code as well, would you ?
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-10-30 10:28
Message:
Logged In: YES
user_id=70434
I need some more informations about this. Please provide
the descriptors and maybe the code as well, would you ?
--
Comment By: Charles Chan (charles_chan)
Date: 2001-10-25 08:22
Message:
Logged In: YES
user_id=198061
I just checked the supplied sample against JBoss in CVS and
I couldn't reproduce the problem.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=472046group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-470697 ] NPE when closing statement
Bugs item #470697, was opened at 2001-10-12 13:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=470697group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: NPE when closing statement Initial Comment: I'm getting a NullPointerException when I close an already closed PreparedStatement. The offending line is org.jboss.pool.jdbc.PreparedStatementInPool.close (PreparedStatementInPool.java:421) I already fixed my application, but I thing this exception should not occur in this case. Thanks, Robson -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=470697group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-463590 ] Entity bean reference is lost
Bugs item #463590, was opened at 2001-09-21 08:50
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463590group_id=22866
Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: Entity bean reference is lost
Initial Comment:
I'm using a stateful session bean to lookup home interfaces for different entity
beans, instantiate
them and return the remote references to the client. This code worked properly with
JBoss 2.2X
but fails with 2.4.1.
Excerpt from sample session bean code:
public CustomerRemote getCustomer( Integer customerPK ) throws RemoteException {
try {
CustomerHome home = (CustomerHome) jndi.lookup( java:comp/env/ejb/Customer );
return clHome.create( customerPK );
}
catch(Exception e) {
e.printStackTrace();
throw new RemoteException(e.getMessage());
}
}
When client calls getCustomer() on the stateful session bean, a new Customer i created
and the
remote customer is returned. Now, when the client makes a call to this newly created
Customer
bean (entity), yet another instance is created, without all the inital data such as
the primary key.
No exceptions thrown, but contents of Customer is of course invalid.
This is part of my ejb-jar.xml:
session
ejb-nameSession/ejb-name
homecom.posten.ejb.SessionHome/home
remotecom.posten.ejb.SessionRemote/remote
ejb-classcom.posten.ejb.Session/ejb-class
session-typeStateful/session-type
transaction-typeBean/transaction-type
ejb-ref
ejb-ref-nameejb/Customer/ejb-ref-name
ejb-ref-typeEntity/ejb-ref-type
homecom.posten.ejb.CustomerHome/home
remotecom.posten.ejb.CustomerRemote/remote
ejb-linkCustomer/ejb-link
/ejb-ref
/session
I'm using Sun JDK 1.3 on a Win NT 4.0 workstation with Oracle Thin Driver 8.1.6.
--
Comment By: Bo Carlsson (boca007)
Date: 2001-10-04 07:41
Message:
Logged In: YES
user_id=167925
Actually, I was able so solve this problem after reading
the J2EE Developer's Guide carefully. As you suspect you
are not guaranteed to get the same bean instance in
successive calls. If the container wishes it creates a new
instance and calls ejbActivate() where the primary from
EntityContext is valid. If needed ejbLoad() is called and
this primary key should be used to refresh data.
Thus, the calls made are:
setEntityContext() Get the context
ejbActivate() Get the primary key from context
ejbLoad() Synchronize data using the primary key
In ver 2.2.2 it seems that the container always kept the
instance where ejbCreate and ejbFindBy* was first invoked.
I recommend you read The Life Cycle of an Entity Bean in
section 4 of J2EE DevGuide.
--
Comment By: Charlie Dobbie (cfmdobbie)
Date: 2001-10-04 06:07
Message:
Logged In: YES
user_id=34788
I seem to be having a similar problem. I have an EJB that
was working correctly under 2.2.2, but now fails on 2.4.1.
I call an ejbFindByX method on the Home interface of my BMP
EJB. My SELECT in the EJB runs correctly and populates a
primary key with the correct data (verified), and returns
it. The client then invokes a method on the Remote
interface which calls a method on the EJB class that calls
EntityContext.getPrimaryKey()... which returns null.
For some reason either the EJB I'm accessing isn't the one
I searched for, or the primary key is being nulled either
before returning the Remote reference, or on any subsequent
access of the EJB.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463590group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-462187 ] Typo in JNDIView
Bugs item #462187, was opened at 2001-09-17 00:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=462187group_id=22866 Category: None Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: Typo in JNDIView Initial Comment: V. low priority this one (JBoss 2.4.0 final): Bound beans that appear in JNDI View under the heading Management are listed as: * jnidName=BoundName Thinking it should be jndiName= ? -- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-30 14:09 Message: Logged In: NO Yep, unless JBoss is implementing a Java Naming and Interface Directory ;-) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=462187group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-462187 ] Typo in JNDIView
Bugs item #462187, was opened at 2001-09-17 00:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=462187group_id=22866 Category: None Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: Typo in JNDIView Initial Comment: V. low priority this one (JBoss 2.4.0 final): Bound beans that appear in JNDI View under the heading Management are listed as: * jnidName=BoundName Thinking it should be jndiName= ? -- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-30 14:09 Message: Logged In: NO Yep, unless JBoss is implementing a Java Naming and Interface Directory ;-) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=462187group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458277 ] EJBException not being propogated
Bugs item #458277, was opened at 2001-09-03 22:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458277group_id=22866
Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: EJBException not being propogated
Initial Comment:
In some instances an EJBException that is thrown from within a business method on a
session bean is not being displayed at the JBoss console. Furthermore the error that
the client calling the business method receives does not contain any reference to the
EJB Exception text as follows:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception
is:
java.rmi.ServerException: Transaction rolled back
java.rmi.ServerException: Transaction rolled back
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke(Unknown
Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:357)
at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123)
at $Proxy1.queryNewFeeCode(Unknown Source)
at FeeManagerUnitTest.testGenerateFeeCode(FeeManagerUnitTest.java:128)
at FeeManagerUnitTest.main(FeeManagerUnitTest.java:144)
The EJBException was thrown from the following code:
// Run this sequence to obtain a fresh fee code.
try {
connection = EjbToolkit.getConnection();
statement = connection.createStatement();
resultSet = statement.executeQuery(FEE_CODE_QUERY);
if (!resultSet.next())
newFeeCode = resultSet.getString(1);
else {
System.out.println(No result!);
- HERE -
throw new EJBException(Failed to generate Fee Code from fee_code_seq
sequence.);
}
}
catch(SQLException se) {
throw new EJBException(Failed to query Fee data: , se);
}
finally {
try {
if (resultSet != null) resultSet.close();
if (statement != null) statement.close();
if (connection != null) connection.close();
}
catch(Exception e) {}
}
The code executes through '- HERE -' then throws the EJBException. The
console output is
[Defaullt] No result!
With no mention of the EJBException...
Dave Elliot
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-02 15:53
Message:
Logged In: YES
user_id=70434
The EJB spec. 1.1 says that when a System Exception is
thrown the container rolls back the transaction or mark it
for a rollback. The System Exception is either a
RuntimeException or RemoteException or any of their
subclasses inclusive EJBException.
Therefore JBoss works correctly and this is not a bug.
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-10-29 21:33
Message:
Logged In: YES
user_id=70434
Can you give the entire code of the EJB, please !
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-10-29 21:32
Message:
Logged In: YES
user_id=70434
Can you give the entire code of the EJB, please !
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458277group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-450615 ] Build instructions????
Bugs item #450615, was opened at 2001-08-13 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=450615group_id=22866 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: Build instructions Initial Comment: There are no build instructions anywhere. Simply downloading the cvs projects listed, and running a build.sh doesn't do the trick. Also, not all the projects are listed. Looking in the developer archive suggested a project called jboss-all, which did put some more stuff on disk, but nothing that made the build run. Firing off ant on some build.xml files also doesn't go very far. So, what are the secret steps to build jboss from source? Thanks! -- Comment By: Andreas Schaefer (schaefera) Date: 2001-10-29 20:21 Message: Logged In: YES user_id=70434 Build current CVS HEAD for Rabbit Hole: - checkout CVS module jboss-all - go to jboss-all/build - start either build.sh or build.bat Run then the builded JBoss instance: - go to jboss-all/build/output/jboss*/bin where * means the current version - start either run.sh or run.bat Further options (inclusive running the test suite): - go to jboss-all/build - start either build.sh help or build.bat help but do not mix this up with build -help - go from there Building components: - go to the component you want like jboss-all/server - start either build.sh or build.bat from there - the compiled code can be found under jboss- all/server/output Andy -- Comment By: Christian Biasuzzi (bchristian) Date: 2001-08-22 03:26 Message: Logged In: YES user_id=220544 I checked-out the whole list of projects listed, including build, thirdparty, tools I renamed folder names according to a config.xml as follows: jboss - server jnp - naming jbossmp - messaging jbosscx - connector jboss-j2ee - j2ee contrib - plugins jbosspool - pool jbosssx - security jbossmx - cluster I copied build/jboss content to build/ and launched build script from there. The former dist folder is now in build/output it worked from me! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=450615group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-448447 ] metadata verifier does not follow dtd
Bugs item #448447, was opened at 2001-08-06 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=448447group_id=22866 Category: JBossServer Group: v2.4 BETA (stable) Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: metadata verifier does not follow dtd Initial Comment: DTD fro ejb2.0 say that abstract-schema-name is optional. But verifier complained loudly. I have developed a quick fix: ( CVS diff below ) ---snip--- Index: EntityMetaData.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/EntityMetaData.java,v retrieving revision 1.10 diff -r1.10 EntityMetaData.java 152c152,154 abstractSchemaName = getElementContent(getUniqueChild(element, abstract-schema-name)); --- // dtd says claerly that this is optional... Element el = getOptionalChild(element, abstract-schema-name); abstractSchemaName = (el == null)? : getElementContent(el); ---snap--- keep a good work... -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-02 16:38 Message: Logged In: YES user_id=70434 Just the definition of the DTD is not enough. You should also check the fine print or the EJB spec. which says: #8226; Entity Bean#8217;s abstract schema name. If the enterprise bean is an Entity Bean with con-tainer- managed persistence and cmp-version 2.x, the Bean Provider must specify the abstract schema name of the entity bean using the abstract- schema-name element. Also the DTD says that a CMP 2 Entity Bean HAS TO PROVIDE an abstract schema name !! Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=448447group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
