Re: [JBoss-dev] JSR-77 and new deployment architecture
- Original Message - From: "Anatoly Akkerman" <[EMAIL PROTECTED]> To: "JBoss-Dev" <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 2:59 PM Subject: [JBoss-dev] JSR-77 and new deployment architecture > > Hi, > > I've been rethinking lately how should the deployment architecture be > redesigned in JBoss for the future clustering support and, incidentally, > my personal project. The existence of JSR-77 which did not put out any > kind of draft yet would, possibly, make our lives more complicated in the > future. But here are some of my ideas about what we may want to develop. Just a reaction for the first part. JSR-77 does not define who applications get deployed. For this is another JSR responsible (JSR-88 or something). Note JSR-77 only declares how you get data from the application server to administer/manage it, but that's all. Andy ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead - New directory
User: danch Date: 01/06/29 21:32:14 jbosstest/src/main/org/jboss/test/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/test Main.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/test Main.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/readahead/test/Main.java
Index: Main.java
===
package org.jboss.test.readahead.test;
import javax.naming.Context;
import javax.naming.InitialContext;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionHome;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionRemote;
import junit.framework.TestCase;
import junit.framework.Test;
import junit.framework.TestSuite;
/**
* TestCase driver for the readahead finder tests
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: Main.java,v 1.1 2001/06/30 04:38:06 danch Exp $
*
* Revision:
*/
public class Main extends TestCase {
CMPFindTestSessionRemote rem = null;
public Main(String name) {
super(name);
}
public static Test suite() {
return new TestSuite(Main.class);
}
protected void tearDown() throws Exception {
if (rem != null) {
System.out.println("Removing test data");
rem.removeTestData();
rem.remove();
rem = null;
}
}
protected void setUp()
throws Exception
{
if (rem != null)
return;
System.out.println("Deploying");
new org.jboss.jmx.client.Deployer().deploy("../deploy/readahead.jar");
System.out.println("Creating test data");
Context ctx = new InitialContext();
CMPFindTestSessionHome home =
(CMPFindTestSessionHome)ctx.lookup("CMPFindTestSession");
rem = home.create();
rem.createTestData();
}
public void testFindAll() throws Exception {
rem.testFinder();
}
public void testFindByCity() throws Exception {
rem.testByCity();
}
public void testAddressByCity() throws Exception {
rem.addressByCity();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin readaheadtest.bat readaheadtest.sh
User: danch Date: 01/06/29 21:38:05 Added: src/bin readaheadtest.bat readaheadtest.sh Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.1 jbosstest/src/bin/readaheadtest.bat Index: readaheadtest.bat === java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main 1.1 jbosstest/src/bin/readaheadtest.sh Index: readaheadtest.sh === #!/bin/sh java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF ejb-jar.xml jaws.xml
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead/META-INF ejb-jar.xml jaws.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/META-INF/ejb-jar.xml
Index: ejb-jar.xml
===
http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
CMPFindTestEntity
org.jboss.test.readahead.interfaces.CMPFindTestEntityHome
org.jboss.test.readahead.interfaces.CMPFindTestEntityRemote
org.jboss.test.readahead.ejb.CMPFindTestEntity
Container
java.lang.String
False
key
name
rank
serialNumber
key
CMPFindTestSession
org.jboss.test.readahead.interfaces.CMPFindTestSessionHome
org.jboss.test.readahead.interfaces.CMPFindTestSessionRemote
org.jboss.test.readahead.ejb.CMPFindTestSession
Stateless
Container
Address
org.jboss.test.readahead.interfaces.AddressHome
org.jboss.test.readahead.interfaces.AddressRemote
org.jboss.test.readahead.ejb.Address
Container
org.jboss.test.readahead.interfaces.AddressPK
False
key
addressId
address
city
state
zip
1.1 jbosstest/src/resources/readahead/META-INF/jaws.xml
Index: jaws.xml
===
CMPFindTestEntity
true
true
findAll
true
findByCity
, address where CMPFindTestEntity.key = address.key AND
address.city = {0}
true
Address
true
true
findByCity
address.city = {0}
true
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead client.policy jndi.properties
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead client.policy jndi.properties
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/client.policy
Index: client.policy
===
grant {
// Allow everything for now
permission java.security.AllPermission;
};
1.1 jbosstest/src/resources/readahead/jndi.properties
Index: jndi.properties
===
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces AddressHome.java AddressPK.java AddressRemote.java CMPFindTestEntityHome.java CMPFindTestEntityRemote.java CMPFindTestSessionHome.java CMPFindTestSessionRemote.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/interfaces
AddressHome.java AddressPK.java AddressRemote.java
CMPFindTestEntityHome.java
CMPFindTestEntityRemote.java
CMPFindTestSessionHome.java
CMPFindTestSessionRemote.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressHome.java
Index: AddressHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: AddressHome.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressHome extends EJBHome {
public AddressRemote create(String key, String addressId, String address,
String city, String state, String zip) throws
RemoteException, CreateException;
public AddressRemote findByPrimaryKey(AddressPK primaryKey) throws
RemoteException, FinderException;
public Collection findByKey(String key) throws RemoteException, FinderException;
public Collection findByCity(String city) throws RemoteException, FinderException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressPK.java
Index: AddressPK.java
===
package org.jboss.test.readahead.interfaces;
import java.io.Serializable;
/**
* Primary key class for one of the entities used in read-ahead finder tests.
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: AddressPK.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public class AddressPK implements Serializable {
public String key = "";
public String addressId = "";
public AddressPK() {
}
public AddressPK(String key, String addressId) {
this.key = key;
this.addressId = addressId;
}
public boolean equals(Object obj) {
if (this.getClass().equals(obj.getClass())) {
AddressPK that = (AddressPK) obj;
return this.key.equals(that.key) && this.addressId.equals(that.addressId);
}
return false;
}
public int hashCode() {
return key.hashCode()+addressId.hashCode();
}
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressRemote.java
Index: AddressRemote.java
===
package org.jboss.test.readahead.interfaces;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/**
* Remote interface for one of the entities used in read-ahead finder tests
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: AddressRemote.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressRemote extends EJBObject {
public java.lang.String getZip() throws RemoteException;
public void setZip(java.lang.String newZip) throws RemoteException;
public java.lang.String getState() throws RemoteException;
public void setState(java.lang.String newState) throws RemoteException;
public java.lang.String getCity() throws RemoteException;
public void setCity(java.lang.String newCity) throws RemoteException;
public void setAddress(java.lang.String newAddress) throws RemoteException;
public java.lang.String getAddress() throws RemoteException;
public java.lang.String getAddressId() throws RemoteException;
public java.lang.String getKey() throws RemoteException;
public void setAddressId(java.lang.String newAddressId) throws RemoteException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/CMPFindTestEntityHome.java
Index: CMPFindTestEntityHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests.
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: CMPFindTestEntityHome.java,
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: danch Date: 01/06/29 21:38:05 Modified:src/build build.xml Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.37 +7 -2 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- build.xml 2001/06/26 01:08:49 1.36 +++ build.xml 2001/06/30 04:38:05 1.37 @@ -148,7 +148,8 @@ - + + @@ -227,7 +228,11 @@ - + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb Address.java CMPFindTestEntity.java CMPFindTestSession.java
User: danch
Date: 01/06/29 21:38:05
Added: src/main/org/jboss/test/readahead/ejb Address.java
CMPFindTestEntity.java CMPFindTestSession.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/readahead/ejb/Address.java
Index: Address.java
===
package org.jboss.test.readahead.ejb;
import javax.ejb.EntityBean;
import javax.ejb.CreateException;
import javax.ejb.RemoveException;
import javax.ejb.EntityContext;
import org.jboss.test.readahead.interfaces.AddressPK;
/**
* Implementation class for one of the entities used in read-ahead finder
* tests
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: Address.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public class Address implements EntityBean {
EntityContext entityContext;
public String key;
public String addressId;
public String address;
public String city;
public String state;
public String zip;
public AddressPK ejbCreate(String key, String addressId, String address,
String city, String state, String zip)
throws CreateException
{
this.key = key;
this.addressId = addressId;
this.address = address;
this.city = city;
this.state = state;
this.zip = zip;
return new AddressPK(key, addressId);
}
public void ejbPostCreate(String key, String addressId, String address,
String city, String state, String zip) throws
CreateException {
}
public void ejbRemove() throws RemoveException {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void ejbLoad() {
}
public void ejbStore() {
}
public void setEntityContext(EntityContext entityContext) {
this.entityContext = entityContext;
}
public void unsetEntityContext() {
entityContext = null;
}
public void setKey(String newKey) {
key = newKey;
}
public String getKey() {
return key;
}
public void setAddressId(String newAddressId) {
addressId = newAddressId;
}
public String getAddressId() {
return addressId;
}
public void setAddress(String newAddress) {
address = newAddress;
}
public String getAddress() {
return address;
}
public void setCity(String newCity) {
city = newCity;
}
public String getCity() {
return city;
}
public void setState(String newState) {
state = newState;
}
public String getState() {
return state;
}
public void setZip(String newZip) {
zip = newZip;
}
public String getZip() {
return zip;
}
}
1.1
jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestEntity.java
Index: CMPFindTestEntity.java
===
package org.jboss.test.readahead.ejb;
import javax.ejb.EntityBean;
import javax.ejb.CreateException;
import javax.ejb.RemoveException;
import javax.ejb.EntityContext;
/**
* Implementation class for one of the entities used in read-ahead finder
* tests
*
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
* @version $Id: CMPFindTestEntity.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public class CMPFindTestEntity implements EntityBean {
EntityContext entityContext;
public String key;
public String name;
public String rank;
public String serialNumber;
private boolean modified;
public String ejbCreate(String key) throws CreateException {
this.key = key;
return key;
}
public boolean isModified() {
return modified;
}
public void ejbPostCreate(String key) throws CreateException {
}
public void ejbRemove() throws RemoveException {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void ejbLoad() {
modified = false;
}
public void ejbStore() {
modified = false;
}
public void setEntityContext(EntityContext entityContext) {
this.entityContext = entityContext;
}
public void unsetEntityContext() {
entityContext = null;
}
public String getKey() {
return key;
}
public void setName(String newName) {
name = newName;
}
public String getName() {
return name;
}
public void setRank(String newRank) {
rank = n
[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-readahead.xml
User: danch Date: 01/06/29 21:38:05 Added: src/build/subprojects build-readahead.xml Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.1 jbosstest/src/build/subprojects/build-readahead.xml Index: build-readahead.xml === ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF - New directory
User: danch Date: 01/06/29 21:34:16 jbosstest/src/resources/readahead/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead - New directory
User: danch Date: 01/06/29 21:33:31 jbosstest/src/resources/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/test - New directory
User: danch Date: 01/06/29 21:32:32 jbosstest/src/main/org/jboss/test/readahead/test - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory
User: danch Date: 01/06/29 21:32:32 jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb - New directory
User: danch Date: 01/06/29 21:32:32 jbosstest/src/main/org/jboss/test/readahead/ejb - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
What did you have to change in build.xml? It also looks like xml.jar is referenced in conf/default/jboss.conf, but I am not sure that it is required or... but I can't really tell if any of those codebase attributes are even used really. If xml.jar is old and it is not being used by anything, lets nuke it. If it is being used (ie. if we remove it and stuff breaks), then lets fix those things that break. --jason On Fri, 29 Jun 2001, danch wrote: > OK, I was able to get on with my lack of a life by making nothing > important in the build file depend on either the ejx or the xmlbeans > targets. This doesn't break my heart, since ejx is not being maintained > (as far as I can tell) and is only serving to leave us dependent on > predeluvian versions of the XML apis. Should I check it in? > > -danch > > danch wrote: > > > More info: > > There's an old version of the xml APIs in the lib directory, in xml.jar. > > This was getting picked up first by javac and causing those problems. > > Removing that so that the classes out of crimson.jar get used causes > > this problem: > > > > java.lang.NoClassDefFoundError: com/sun/xml/tree/XmlDocument > > at > > com.dreambean.xmlbeans.BeanInfoCompiler.(BeanInfoCompiler.java:109) > > at com.dreambean.xmlbeans.ant.XMLBeans.execute(XMLBeans.java:44) > > at org.apache.tools.ant.Target.execute(Target.java:153) > > at org.apache.tools.ant.Project.runTarget(Project.java:898) > > at org.apache.tools.ant.Project.executeTarget(Project.java:536) > > at org.apache.tools.ant.Project.executeTargets(Project.java:510) > > at org.apache.tools.ant.Main.runBuild(Main.java:421) > > at org.apache.tools.ant.Main.main(Main.java:149) > > > > > > Slay me with a rubber spoon! Anybody know where sources might be? > > > > thanks, > > danch > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
JBoss daily test results SUMMARY Number of tests run: 86 Successful tests: 81 Errors:1 Failures: 4 [time of test: 30 June 2001 2:49] 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 Suite: org.jboss.test.xa.test.Main Test:testXABean Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound; nested exception is: javax.ejb.EJBException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound Stack Trace: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound; nested exception is: javax.ejb.EJBException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound java.rmi.ServerException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound; nested exception is: javax.ejb.EJBException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound javax.ejb.EJBException: Unable to find DB pool: javax.naming.NameNotFoundException: XADataSource1 not bound 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:362) at org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123) at $Proxy1.clearData(Unknown Source) at org.jboss.test.xa.test.Main.testXABean(Main.java:106) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.jmsra.test.AllJUnitTests Test:testSimple Type:failure Exception: junit.framework.AssertionFailedError Message: Stack Trace: junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:143) at junit.framework.Assert.assert(Assert.java:19) at junit.framework.Assert.assert(Assert.java:26) at org.jboss.test.jmsra.test.RaTest.testSimple(RaTest.java:101) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.jmsra.test.AllJUnitTests Test:testBeanOk Type:failure Exception: junit.framework.AssertionFailedError Message: Stack Trace: junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:143) at junit.framework.Assert.assert(Assert.java:19) at junit.framework.Assert.assert(Assert.java:26) at org.jboss.test.jmsra.test.RaTest.testBeanOk(RaTest.java:119) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.ru
Re: [JBoss-dev] Build problem with CVS HEAD
The src/build/build.xml file says that xml.jar is only there to support ejx.
Is that true? Does anyone know if it is being used anywhere else? If not
lets get rid of it.
--jason
On Fri, 29 Jun 2001, danch wrote:
> More info:
> There's an old version of the xml APIs in the lib directory, in xml.jar.
> This was getting picked up first by javac and causing those problems.
> Removing that so that the classes out of crimson.jar get used causes
> this problem:
>
> java.lang.NoClassDefFoundError: com/sun/xml/tree/XmlDocument
> at com.dreambean.xmlbeans.BeanInfoCompiler.(BeanInfoCompiler.java:109)
> at com.dreambean.xmlbeans.ant.XMLBeans.execute(XMLBeans.java:44)
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> at org.apache.tools.ant.Main.runBuild(Main.java:421)
> at org.apache.tools.ant.Main.main(Main.java:149)
>
>
> Slay me with a rubber spoon! Anybody know where sources might be?
>
> thanks,
> danch
>
>
> danch wrote:
>
> > The last couple of days I've been unable to build the HEAD version from
> > CVS. It looks like yet another XML parser version mismatch (YAXPVM? OK,
> > that's we nobody has used that acronym before).
> >
> > I've blown out everything under the jboss directory and god fresh via
> > `cvs update -d` and that didn't help. I've also run the build script
> > with an empty CLASSPATH (which shouldn't be neccessary with ant) and had
> > no joy.
> >
> > Here are the errors:
> >
> > /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:382:
> > Method hasAttribute(java.lang.String) not found in interface
> > org.w3c.dom.Element.
> > [javac] if( pObjectName.hasAttribute( "name" ) ) {
> > [javac] ^
> > [javac]
> > /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:387:
> > Method hasAttribute(java.lang.String) not found in interface
> > org.w3c.dom.Element.
> > [javac] if( pObjectName.hasAttribute( "domain" ) ) {
> > [javac] ^
> > [javac]
> > /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:394:
> > Method hasAttribute(java.lang.String) not found in interface
> > org.w3c.dom.Element.
> > [javac] if( lProperty.hasAttribute( "key" ) &&
> > lProperty.hasChildNodes() ) {
> > [javac] ^
> > [javac]
> > /work/danch/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java:135:
> > Method getPublicId() not found in interface org.w3c.dom.DocumentType.
> > [javac] publicID = docType.getPublicId();
> > [javac]^
> > [javac] Note: 5 files use or override a deprecated API. Recompile
> > with "-deprecation" for details.
> > [javac] 4 errors, 1 warning
> >
> >
> >
> >
> > P.S. Should we turn on deprecation in the build. Those make me feel like
> > C++ warnings used to in the old days.
> >
> >
> > thanks all,
> > danch
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
I can build it just fine. Perhaps you have some extra fluff in your
classpath?
--jason
On Fri, 29 Jun 2001, danch wrote:
> The last couple of days I've been unable to build the HEAD version from
> CVS. It looks like yet another XML parser version mismatch (YAXPVM? OK,
> that's we nobody has used that acronym before).
>
> I've blown out everything under the jboss directory and god fresh via
> `cvs update -d` and that didn't help. I've also run the build script
> with an empty CLASSPATH (which shouldn't be neccessary with ant) and had
> no joy.
>
> Here are the errors:
>
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:382:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( pObjectName.hasAttribute( "name" ) ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:387:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( pObjectName.hasAttribute( "domain" ) ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:394:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( lProperty.hasAttribute( "key" ) &&
> lProperty.hasChildNodes() ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java:135:
> Method getPublicId() not found in interface org.w3c.dom.DocumentType.
> [javac] publicID = docType.getPublicId();
> [javac]^
> [javac] Note: 5 files use or override a deprecated API. Recompile
> with "-deprecation" for details.
> [javac] 4 errors, 1 warning
>
>
>
>
> P.S. Should we turn on deprecation in the build. Those make me feel like
> C++ warnings used to in the old days.
>
>
> thanks all,
> danch
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
OK, I was able to get on with my lack of a life by making nothing important in the build file depend on either the ejx or the xmlbeans targets. This doesn't break my heart, since ejx is not being maintained (as far as I can tell) and is only serving to leave us dependent on predeluvian versions of the XML apis. Should I check it in? -danch danch wrote: > More info: > There's an old version of the xml APIs in the lib directory, in xml.jar. > This was getting picked up first by javac and causing those problems. > Removing that so that the classes out of crimson.jar get used causes > this problem: > > java.lang.NoClassDefFoundError: com/sun/xml/tree/XmlDocument > at > com.dreambean.xmlbeans.BeanInfoCompiler.(BeanInfoCompiler.java:109) > at com.dreambean.xmlbeans.ant.XMLBeans.execute(XMLBeans.java:44) > at org.apache.tools.ant.Target.execute(Target.java:153) > at org.apache.tools.ant.Project.runTarget(Project.java:898) > at org.apache.tools.ant.Project.executeTarget(Project.java:536) > at org.apache.tools.ant.Project.executeTargets(Project.java:510) > at org.apache.tools.ant.Main.runBuild(Main.java:421) > at org.apache.tools.ant.Main.main(Main.java:149) > > > Slay me with a rubber spoon! Anybody know where sources might be? > > thanks, > danch > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB problem with latest CVS?
Thanks, I was having trouble finding this information. Is this documented anywhere? Do you have any clues about the EOFException problem that I am getting? --jason On Fri, 29 Jun 2001, Hiram Chirino wrote: > > The OIL (stands for Optimized Invocation Layer). Just means that we use a > custom socket level protocol to talk to the server. Every connection > established uses 2 sockets (#1 for the client to talked to the server, and > #2 for the server to 'push' async messages to the client). The seconds > socket is established by the server connecting to the client, so this could > be not such a good thing for clients behind a firewall. The UIL try to > solve this problem. > > The UIL (stands for Unified Invocation Layer) uses the same basic socket > protocol that the OIL uses but it under it It also places a socket > multiplexing protocol so that it creates 2 "virtual" sockets out the one > physical socket the client established to the server. > > Regards, > Hiram > > >From: Jason Dillon <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: [JBoss-dev] MDB problem with latest CVS? > >Date: Wed, 27 Jun 2001 18:14:55 -0700 (PDT) > > > >Hey, I had to stop playing with build systems and get some actual work > >done. > >I was finishing up integrating the JMS RA support, so my application has > >better JMS/EJB TX integration and I started getting messages like the > >snippet below. The application seems to behave as normal, but I am > >concerned that this might cause problems underload. > > > >This seems to happen quite frequently. I breifly looked into the > >exception, > >but it is not obvious to me what might be wrong, or even if there is > >something wrong at all. > > > >On a related note could someone explain what the difference between UIL and > >OIL is? > > > > > >java.io.EOFException > > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > >Container factory [ConnectionReceiverOIL Server] WARN - MDB lost > >connection > >to provider > >Container factory [ConnectionReceiverOIL Server] INFO - MDB Trying to > >reconnect... > > at > >>org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > > at java.lang.Thread.run(Thread.java:484) > >Container factory [ConnectionReceiverOIL Server] DEBUG - Destroying > >JMSContainerInvoker > >Container factory [ConnectionReceiverOIL Server] DEBUG - Clearing 15 from > >ServerSessionPool > >Container factory [ConnectionReceiverOIL Server] DEBUG - Got destination > >type Queue > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >java.io.EOFException > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > > at > >>org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > > at java.lang.Thread.run(Thread.java:484) > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > >for session > >Container factory [ConnectionReceiverOIL Server] DEBUG - Server Session > >pool > >set up > >Container factory [ConnectionReceiverOIL Server] DEBUG - Queue > >connectionConsumer set up > >Container factory [ConnectionReceiverOIL Server] DEBUG - Starting > >JMSContainerInvoker > >Container factory [ConnectionReceiverOIL Server] INFO - OK - reconnected > > > > > >--jason > > > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >http://lists.sourceforge.net/lists/listinfo/jboss-development > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > htt
Re: [JBoss-dev] MDB problem with latest CVS?
I am currently running everything on the same machine. I am correct in beliving that this would not be a bug in the JMS RA? I am just trying to narrow the scope of the hunt for this problem. Does anyone know if the EOFException in this case is an error or more of a notification? --jason On Fri, 29 Jun 2001 [EMAIL PROTECTED] wrote: > On 27 Jun, Jason Dillon wrote: > > Hey, I had to stop playing with build systems and get some actual work done. > > I was finishing up integrating the JMS RA support, so my application has > > better JMS/EJB TX integration and I started getting messages like the > > snippet below. The application seems to behave as normal, but I am > > concerned that this might cause problems underload. > > > > This seems to happen quite frequently. I breifly looked into the exception, > > but it is not obvious to me what might be wrong, or even if there is > > something wrong at all. > > This is the failsafe code in the invoker doing it's work. If you remote > server (where the destinations are) was down, there is nothin g to worry > about. If not, it is probably a bug in JBossMQ (take it on the JBossMQ > mailinglist). > > //Peter > > > > On a related note could someone explain what the difference between UIL and > > OIL is? > > > > > > java.io.EOFException > > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > > Container factory [ConnectionReceiverOIL Server] WARN - MDB lost connection > > to provider > > Container factory [ConnectionReceiverOIL Server] INFO - MDB Trying to > > reconnect... > > at > > >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > > at java.lang.Thread.run(Thread.java:484) > > Container factory [ConnectionReceiverOIL Server] DEBUG - Destroying > > JMSContainerInvoker > > Container factory [ConnectionReceiverOIL Server] DEBUG - Clearing 15 from > > ServerSessionPool > > Container factory [ConnectionReceiverOIL Server] DEBUG - Got destination > > type Queue > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > java.io.EOFException > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > > at > > >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > > at java.lang.Thread.run(Thread.java:484) > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > > for session > > Container factory [ConnectionReceiverOIL Server] DEBUG - Server Session pool > > set up > > Container factory [ConnectionReceiverOIL Server] DEBUG - Queue > > connectionConsumer set up > > Container factory [ConnectionReceiverOIL Server] DEBUG - Starting > > JMSContainerInvoker > > Container factory [ConnectionReceiverOIL Server] INFO - OK - reconnected > > > > > > --jason > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
More info:
There's an old version of the xml APIs in the lib directory, in xml.jar.
This was getting picked up first by javac and causing those problems.
Removing that so that the classes out of crimson.jar get used causes
this problem:
java.lang.NoClassDefFoundError: com/sun/xml/tree/XmlDocument
at com.dreambean.xmlbeans.BeanInfoCompiler.(BeanInfoCompiler.java:109)
at com.dreambean.xmlbeans.ant.XMLBeans.execute(XMLBeans.java:44)
at org.apache.tools.ant.Target.execute(Target.java:153)
at org.apache.tools.ant.Project.runTarget(Project.java:898)
at org.apache.tools.ant.Project.executeTarget(Project.java:536)
at org.apache.tools.ant.Project.executeTargets(Project.java:510)
at org.apache.tools.ant.Main.runBuild(Main.java:421)
at org.apache.tools.ant.Main.main(Main.java:149)
Slay me with a rubber spoon! Anybody know where sources might be?
thanks,
danch
danch wrote:
> The last couple of days I've been unable to build the HEAD version from
> CVS. It looks like yet another XML parser version mismatch (YAXPVM? OK,
> that's we nobody has used that acronym before).
>
> I've blown out everything under the jboss directory and god fresh via
> `cvs update -d` and that didn't help. I've also run the build script
> with an empty CLASSPATH (which shouldn't be neccessary with ant) and had
> no joy.
>
> Here are the errors:
>
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:382:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( pObjectName.hasAttribute( "name" ) ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:387:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( pObjectName.hasAttribute( "domain" ) ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:394:
> Method hasAttribute(java.lang.String) not found in interface
> org.w3c.dom.Element.
> [javac] if( lProperty.hasAttribute( "key" ) &&
> lProperty.hasChildNodes() ) {
> [javac] ^
> [javac]
> /work/danch/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java:135:
> Method getPublicId() not found in interface org.w3c.dom.DocumentType.
> [javac] publicID = docType.getPublicId();
> [javac]^
> [javac] Note: 5 files use or override a deprecated API. Recompile
> with "-deprecation" for details.
> [javac] 4 errors, 1 warning
>
>
>
>
> P.S. Should we turn on deprecation in the build. Those make me feel like
> C++ warnings used to in the old days.
>
>
> thanks all,
> danch
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build problem with CVS HEAD
The last couple of days I've been unable to build the HEAD version from
CVS. It looks like yet another XML parser version mismatch (YAXPVM? OK,
that's we nobody has used that acronym before).
I've blown out everything under the jboss directory and god fresh via
`cvs update -d` and that didn't help. I've also run the build script
with an empty CLASSPATH (which shouldn't be neccessary with ant) and had
no joy.
Here are the errors:
/work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:382:
Method hasAttribute(java.lang.String) not found in interface
org.w3c.dom.Element.
[javac] if( pObjectName.hasAttribute( "name" ) ) {
[javac] ^
[javac]
/work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:387:
Method hasAttribute(java.lang.String) not found in interface
org.w3c.dom.Element.
[javac] if( pObjectName.hasAttribute( "domain" ) ) {
[javac] ^
[javac]
/work/danch/jboss/jboss/src/main/org/jboss/jmx/server/XMLAdaptorImpl.java:394:
Method hasAttribute(java.lang.String) not found in interface
org.w3c.dom.Element.
[javac] if( lProperty.hasAttribute( "key" ) &&
lProperty.hasChildNodes() ) {
[javac] ^
[javac]
/work/danch/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java:135:
Method getPublicId() not found in interface org.w3c.dom.DocumentType.
[javac] publicID = docType.getPublicId();
[javac]^
[javac] Note: 5 files use or override a deprecated API. Recompile
with "-deprecation" for details.
[javac] 4 errors, 1 warning
P.S. Should we turn on deprecation in the build. Those make me feel like
C++ warnings used to in the old days.
thanks all,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] METHOD-INVOCATION (introducing profiling support)
Hi,
I like the idea of being able to pass arbitrary contexts
with the invocation request.
I guess that it means we should agree to some context
naming convention.
Are you talking about org.jboss.ejb.MethodInvocation?
Why should that class be Serializable?
It is only used locally on the server.
I guess that a Map would be right for the contexts
of the MI, but IMHO we should only use it for optional
context information. The mandatory context information
(like the Method and argument list, and possibly tx,
principal and credentials), we should keep in seperate
variables in the MI to avoid the Map lookup.
The MI is passed forth and back in the invocation
chain, so we could use that to pass context changes
back towards the caller within the local VM.
For passing contexts across the wire: This depends on
the invocation transport used, and not all transports
may support it.
For the JRMP transport, org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
has same role as MI over the wire.
I guess that it could be changed to support contexts.
But it is only passed in the invocation request, and
not returned with the invocation reply. If we want to
pass context changes back to the caller (and we want
that, we may want it even in case of exceptions), I
guess that we have to package all invocation replies
(return values and returned exceptions) into some
return value object over the wire.
Best Regards,
Ole Husgaard.
P.S: I'll better go nuke that TPC import in the MI
now...
"Jung , Dr. Christoph" wrote:
>
> -Ursprüngliche Nachricht-
> >Von: marc fleury [mailto:[EMAIL PROTECTED]]
> >Gesendet: Donnerstag, 28. Juni 2001 18:03
> >An: [EMAIL PROTECTED]
> >Betreff: RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling
> >support)
>
> >I believe we should in fact move EVERYTHING to the map, the user the method
> >the tx everything
> >so that the MI is just a big
>
> >MI {
> >Map
> >}
>
> >and in the map we have pairs
> >user Object
> >method Object
> >params Object[]
> >myInformationThatIOnlyUseInMyOwnLittleApplication
> >Object[Maps[Array[OfMyStuff
>
> >would that cut it? yes we pay a price (map lookup) but it is on a small
> >map.
>
> that would perfectly cut it.
>
> >The only tricky part is that it needs to be serializable, (or not actually
> >but we would need to write the map item by item and catch the
> >non-serializability).
>
> as a first approach I would say that it is in the responsibility of the
> invoker/interceptor
> developers to either put only serializable instances in there or to remove
> any non-serializable stuff
> before returning to their predecessor in the chain
>
> ... now that I write it, there was once this idea of having
> a "tree of responsibility" or at least of several invokers feeding the same
> chain, maybe we could realise this also in RabbitHole? ...
>
> hence we could rely on a serializable HashMap or whatever.
>
> I´d be glad to assist you wherever possible in that respect ...
>
> CGJ
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JSR-77 and new deployment architecture
Hi, I've been rethinking lately how should the deployment architecture be redesigned in JBoss for the future clustering support and, incidentally, my personal project. The existence of JSR-77 which did not put out any kind of draft yet would, possibly, make our lives more complicated in the future. But here are some of my ideas about what we may want to develop. App repository infrastructure - keeps archives of applications with versioning information - applications are kept in a pristine EAR form (more about this later) App configuration/packaging infrastructure - can have some modules to help create a pristine EAR - can take a pristine EAR (say, from the app repository) and add or modify any module deployment XMLs to suit a particular deployment scenario - can split a pristine EAR into pieces (modules) keeping consistent class dependencies and libraries App runtime representation/profiling infrastructure - keeps runtime information of the application deployed in a particular deployment scenario: + which JBoss nodes have which modules deployed and how are the modules referencing each other + keeps profiling data (if enabled, also it should be configurable to support different profiling granularity with different overheads) about the running application App deployment/migration/undeployment infrastructure - manages deployment/internode migration (if we ever support this)/undeployment of application modules on JBoss nodes in the scope of the given application deployment (thank you Dr. Jung for scoped deployment support) We can have GUI plugins for the management application to assist in various steps of controlling this stuff. So, my vision is, we take a pristine EAR, like PetStore. Drop it into the repository. The App configuration/packaging service analyzes the EAR and keeps track of the modules, their connectivity, dependencies, offering you, perhaps, a GUI interface that brings up a graph of the application and you specify where to deploy each module and how. We can offer a default path (ala hot-deploy) of deploying the app on a single node. The conf/packager repackages and reconfigures the pristine EAR into a collection of modules (keeping track of class dependencies and providing necessary libraries for modules) which get deployed on approriate nodes by the deployment infrastructure. The runtime representation gets the current scenario and collects profiling information from each module. Just to add some spice to this, put in an Adaptation Manager into this that tries to enhance performance by analyzing the profiling data and dynamically deploying/migrating/undeploying modules. But this is really what my research is about, so that would have to wait :) I have scratched a few of the problems a little (like splitting an application into modules, dynamic deployment descriptor generation, etc.) I have very little code yet (some dependency analysis, app structure extraction) but perhaps, throwing these ideas here will get more people thinking about it, designing and implementing it. As a side note, I remember, that when Dr. Jung submitted his ScopedDeployment stuff, they had a discussion with Mark about module deployment ordering and circular class dependencies in beans (modules). I think, the conf/packaging service can obtain enough information from the pristine app to be able to inform the deployer service on the proper order and also take care of circular class dependencies. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB problem with latest CVS?
The OIL (stands for Optimized Invocation Layer). Just means that we use a custom socket level protocol to talk to the server. Every connection established uses 2 sockets (#1 for the client to talked to the server, and #2 for the server to 'push' async messages to the client). The seconds socket is established by the server connecting to the client, so this could be not such a good thing for clients behind a firewall. The UIL try to solve this problem. The UIL (stands for Unified Invocation Layer) uses the same basic socket protocol that the OIL uses but it under it It also places a socket multiplexing protocol so that it creates 2 "virtual" sockets out the one physical socket the client established to the server. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: [JBoss-dev] MDB problem with latest CVS? >Date: Wed, 27 Jun 2001 18:14:55 -0700 (PDT) > >Hey, I had to stop playing with build systems and get some actual work >done. >I was finishing up integrating the JMS RA support, so my application has >better JMS/EJB TX integration and I started getting messages like the >snippet below. The application seems to behave as normal, but I am >concerned that this might cause problems underload. > >This seems to happen quite frequently. I breifly looked into the >exception, >but it is not obvious to me what might be wrong, or even if there is >something wrong at all. > >On a related note could someone explain what the difference between UIL and >OIL is? > > >java.io.EOFException > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) >Container factory [ConnectionReceiverOIL Server] WARN - MDB lost >connection >to provider >Container factory [ConnectionReceiverOIL Server] INFO - MDB Trying to >reconnect... > at >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > at java.lang.Thread.run(Thread.java:484) >Container factory [ConnectionReceiverOIL Server] DEBUG - Destroying >JMSContainerInvoker >Container factory [ConnectionReceiverOIL Server] DEBUG - Clearing 15 from >ServerSessionPool >Container factory [ConnectionReceiverOIL Server] DEBUG - Got destination >type Queue >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >java.io.EOFException >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > at >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > at java.lang.Thread.run(Thread.java:484) >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener >for session >Container factory [ConnectionReceiverOIL Server] DEBUG - Server Session >pool >set up >Container factory [ConnectionReceiverOIL Server] DEBUG - Queue >connectionConsumer set up >Container factory [ConnectionReceiverOIL Server] DEBUG - Starting >JMSContainerInvoker >Container factory [ConnectionReceiverOIL Server] INFO - OK - reconnected > > >--jason > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >http://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] write access to cvs repository
You demonstrate you know what your doing by submitting patches to sourceforge and when the volume and/or quality justifies write access Marc will approve it. - Original Message - From: "Mikael Tollefsen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 1:41 PM Subject: [JBoss-dev] write access to cvs repository > How do I get write access to the cvs repository? > > > Mikael Tollefsen > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] write access to cvs repository
How do I get write access to the cvs repository? Mikael Tollefsen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where is everyone today?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Friday, June 29, 2001 3:16 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] Where is everyone today?
>
>
> Bill,
>
> Thanks for the reply. I really need other people thinking about this,
> because I don't understand the rest of the container.
>
IMHO, you shouldn't have to understand the rest of the container. If you
use the HOME interfaces, everything will be abstracted out and taken care of
for you.
> Here's the deal. I delegate the actual storage of the other updated
> contexts to the their respective persistence storage managers, so they get
> stored by correct data source. I also get references to the other beans
> through their container's cache.
>
Again, why do you talk directly with the Persistent managers? Entities
always know when they have to store themselves. You really don't have to
worry about it.
> I think the biggest problem with this implementation is that my
> persistence
> store is directly calling store on other persistence stores, thus
> by passing
> all of the code that is supposed know the right way to do this.
>
I just read a little about the CMR stuff in the spec. Seems pretty nasty to
implement and probably effects more things than just the persistent store.
It seems that Relationships must be first class remote objects that wrap
access to their underlying entities. I'd be curious to know how you handle
one-to-many relationships i.e.
from the spec:
public void changeTelephoneNumbers()
{
Address a = getShippingAddress();
Address b = getBillingAddress();
Collection c = b.getTelephoneNumbers();
a.setTelephoneNumbers(b.getTelephoneNumbers());
if (c.isEmpty()) { // must be true!
...
}
> Again, I don't know if I'm doing something wrong. I could post
> the section
> of code that does this, if it will help.
>
Why don't you check-in the code to your CMP directory structure? Then
everybody can see it. This stuff is a "work in progress" anyways, isn't it?
Also, I'm interested in helping out with this relationship stuff. Danch
probably is even more interested, but I can't speak for him.
Regards,
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where is everyone today?
Seems like it's always an interesting tradeoff of whether the code belongs in some runtime code (persistence manager) or in the generated code (CMP bean implementation)... I'm glad you're working on CMP 2.0, it will be good to have that implemented or JBoss. Cheers -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 3:22 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:01 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Where is everyone today? > > > I would think you'd want to be out of the guts too, that just > seems a bit > too closely coupled with JBoss for the persistence manager. > Shouldn't the > CMP persistence manager be some type of layer on top (well > almost on top) > with a well defined interface? This should clearly tie in to > take advantage > of what the container can provide. > > I am definitely on the outside of JBoss though, so marc et al > are the people > to listen to. > > Cheers > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the transaction? Do I > > > need to lock the > > > context? What if one of the beans is removed? (the new remove > > > procedure for > > > relationships may handle this, but haven't implemented it yet) > > > > > > As you can tell this has given me a lot of concern. If > this is stuff I > > > shouldn't worry about, good. If I should worry, will it be > > > better to create > > > the new interceptor, thus reusing the code in the other > > > interceptors, or > > > will it be easier to handle the few special cases in the > > > persistence store? > > > > > > -dain > > > > > > > -Original Message- > > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 9:53 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] CMP 2
Re: [JBoss-dev] Where is everyone today?
Dain Sundstrom wrote: > Bill, > > Thanks for the reply. I really need other people thinking about this, > because I don't understand the rest of the container. > > Here's the deal. I delegate the actual storage of the other updated > contexts to the their respective persistence storage managers, so they get > stored by correct data source. I also get references to the other beans > through their container's cache. Errr. I was nervous enough about the persistence manager messing with its own bean's cache, let along messing with other bean's caches. > > I think the biggest problem with this implementation is that my persistence > store is directly calling store on other persistence stores, thus by passing > all of the code that is supposed know the right way to do this. Ya, this makes me nervous too - there's too much that can go wrong. Really to get the store going you should be hooking into the transaction (which is the job of the EntitySynchronizationInterceptor) What about Bill's suggestion to go through the homes? That may not be the best performance, but then you know that all the Right Things are happening, even if (when) the definition of Right Thing changes. Short circuiting the interceptor chain is bad, IMHO. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
And if anyone bothers to check it, can someone please go thru the multiple datasources code I'd sent? It only makes sense to have it at a bean level - cannot think of an enterprise app connecting to single database! - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 8:22 PM Subject: RE: [JBoss-dev] Where is everyone today? > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > > -Original Message- > > From: Jay Walters [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:01 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > I would think you'd want to be out of the guts too, that just > > seems a bit > > too closely coupled with JBoss for the persistence manager. > > Shouldn't the > > CMP persistence manager be some type of layer on top (well > > almost on top) > > with a well defined interface? This should clearly tie in to > > take advantage > > of what the container can provide. > > > > I am definitely on the outside of JBoss though, so marc et al > > are the people > > to listen to. > > > > Cheers > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:53 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > Yo Dain, > > > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > > really worried that you are working directly with > > EntityEnterpriseContexts > > from the container.cache. Why aren't you going through the > > HOME interfaces > > to access related beans? Remember, each entity type can have entirely > > different datastores, caching mechanisms, locking mechanisms, > > synchronization mechanisms, and pooling mechanisms. You > > shouldn't really be > > circumventing how to access a bean. If I'm totally out of my > > league here, > > I'll just apologize and shut up. Let me know, but in the > > meantime, I'll try > > to review the CMP 2.x Relationships. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Dain > > > Sundstrom > > > Sent: Friday, June 29, 2001 2:22 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: [JBoss-dev] Where is everyone today? > > > > > > > > > Is everyone on vacation? Is the list working? What-ever, > > doesn't really > > > matter. > > > > > > If any one is around today, and can reply to my message, I > > would greatly > > > appreciate it. I kind of need some guidance on the decision > > to create an > > > interceptor or not. I'm going to continue along the line that I > > > don't need > > > an interceptor (I can always add it later). > > > > > > If you all are on vacation, have a great time. > > > > > > -dain > > > > > > > -Original Message- > > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 11:48 PM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > > > > marc, > > > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > > working using the > > > > entity cache, but it gives me a bad feeling. In the this > > > > case, there may be > > > > up to 4 beans that need to be stored: > > > > > > > > before: > > > > a1--b1 > > > > a2--b2 > > > > > > > > a1.setB(b2) > > > > > > > > after: > > > > a1\ b1 > > > > a2 \b2 > > > > > > > > So, I hold onto up to three other contexts. When my store is > > > > called, I write > > > > my state and then store the other contexts (with their > > > > respective mangers). > > > > This won't cause extraneous writes as 'tuned updates' is > > always on. > > > > > > > > What is giving me the bad feeling is I have just cut out all > > > > of the work > > > > that is being done in the interceptors, specifically > > > > EntitySynchronizationInterceptor. For example, do I need > > to remove the > > > > context from the cache at the end of the transaction? Do I > > > > need to lock the > > > > context? What if one of the beans is removed? (the new remove > > > > procedure for > > > > relationships may handle this, but haven't implemented it yet) > > > > > > > > As you can tell this has given me a lot of concern. If > > this is stuff I > > > > shouldn't worry about, good. If I should worry, will it be > > > > better to create > > > > the new interceptor, thus reusing the code in the other > > > > interceptors, or > > > > will it be easier to handle the few special cases in the > > > > persistence store? > > > > > > > > -dain > > > > > >
Re: [JBoss-dev] Shutting down JBoss
Well, Shutting down is on half of the story ain't it? You obviously want to restart the server you shut down at some point of time! I'll try going thru the these startup and shutdown classes and see if I can come up with anything! Thanks, Vinay PS: Thanks for the correcting the threads!=processes thing. just makes it easier to putting a ps -ef output as processes! - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 8:10 PM Subject: RE: [JBoss-dev] Shutting down JBoss > Works great for me on Linux. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > > Mulder > > Sent: Friday, June 29, 2001 2:56 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Shutting down JBoss > > > > > > On Fri, 29 Jun 2001, Bill Burke wrote: > > > You can shut it down very easy from the JMX interface. Starting up is a > > > different story. > > > > Last time I tried this, it unloaded all the beans and services, > > but did not actually cause the JVM to exit, so JBoss was still taking a > > boatload of system resources. Is there a "shutdown and exit" option now? > > > > Aaron > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Shutting down JBoss
The org.jboss.Shutdown works fine for me to shut down JBoss also from /etc/init.d on SuSE Linux 7.1. Andy > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 12:13 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Shutting down JBoss > > > There are two classes for this: > > org.jboss.jmx.client.Stop > org.jboss.Shutdown > > I don't know how well they work. Shutdown just invokes the shudown > method on the Shutdown service which you can do using the JMS > html adaptor. > > - Original Message - > From: "Vinay Menon" <[EMAIL PROTECTED]> > To: "Dev @ JBoss" <[EMAIL PROTECTED]> > Sent: Friday, June 29, 2001 11:32 AM > Subject: [JBoss-dev] Shutting down JBoss > > > Alright, > This might sound a bit naive but do we need a > little simple gui that one can use to shut down JBoss or > restart it? When > you run JBoss on the command line in Unix as a background > process [./run.sh&] it spawns loads of java processes that need to be > killed. Is there a cleaner way to do this? > > Vinay > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
The first implementation of the read-ahead messed around with the caches before I decided that I didn't like it and took that out. -danch Dain Sundstrom wrote: > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > >>-Original Message- >>From: Jay Walters [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:01 PM >>To: '[EMAIL PROTECTED]' >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>I would think you'd want to be out of the guts too, that just >>seems a bit >>too closely coupled with JBoss for the persistence manager. >>Shouldn't the >>CMP persistence manager be some type of layer on top (well >>almost on top) >>with a well defined interface? This should clearly tie in to >>take advantage >>of what the container can provide. >> >>I am definitely on the outside of JBoss though, so marc et al >>are the people >>to listen to. >> >>Cheers >> >>-Original Message- >>From: Bill Burke [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:53 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>Yo Dain, >> >>I know absolutely nothing about CMP 2.x Relationships, but it makes me >>really worried that you are working directly with >>EntityEnterpriseContexts >>from the container.cache. Why aren't you going through the >>HOME interfaces >>to access related beans? Remember, each entity type can have entirely >>different datastores, caching mechanisms, locking mechanisms, >>synchronization mechanisms, and pooling mechanisms. You >>shouldn't really be >>circumventing how to access a bean. If I'm totally out of my >>league here, >>I'll just apologize and shut up. Let me know, but in the >>meantime, I'll try >>to review the CMP 2.x Relationships. >> >>Bill >> >> >>>-Original Message- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED]]On >>> >>Behalf Of Dain >> >>>Sundstrom >>>Sent: Friday, June 29, 2001 2:22 PM >>>To: '[EMAIL PROTECTED]' >>>Subject: [JBoss-dev] Where is everyone today? >>> >>> >>>Is everyone on vacation? Is the list working? What-ever, >>> >>doesn't really >> >>>matter. >>> >>>If any one is around today, and can reply to my message, I >>> >>would greatly >> >>>appreciate it. I kind of need some guidance on the decision >>> >>to create an >> >>>interceptor or not. I'm going to continue along the line that I >>>don't need >>>an interceptor (I can always add it later). >>> >>>If you all are on vacation, have a great time. >>> >>>-dain >>> >>> -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is >>always on. >> What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need >>to remove the >> context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If >>this is stuff I >> shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain >-Original Message- >From: marc fleury [mailto:[EMAIL PROTECTED]] >Sent: Thursday, June 28, 2001 9:53 PM >To: [EMAIL PROTECTED] >Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > >also be sure to report right here is you touch any of the >information in the >ctx (using setters) > >marcf > >|-Original Message- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On >Behalf Of Dain >|Sundstrom >|Sent: Thursday
RE: [JBoss-dev] Where is everyone today?
Bill, Thanks for the reply. I really need other people thinking about this, because I don't understand the rest of the container. Here's the deal. I delegate the actual storage of the other updated contexts to the their respective persistence storage managers, so they get stored by correct data source. I also get references to the other beans through their container's cache. I think the biggest problem with this implementation is that my persistence store is directly calling store on other persistence stores, thus by passing all of the code that is supposed know the right way to do this. Again, I don't know if I'm doing something wrong. I could post the section of code that does this, if it will help. -dain > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 1:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the transaction? Do I > > > need to lock the > > > context? What if one of the beans is removed? (the new remove > > > procedure for > > > relationships may handle this, but haven't implemented it yet) > > > > > > As you can tell this has given me a lot of concern. If > this is stuff I > > > shouldn't worry about, good. If I should worry, will it be > > > better to create > > > the new interceptor, thus reusing the code in the other > > > interceptors, or > > > will it be easier to handle the few special cases in the > > > persistence store? > > > > > > -dain > > > > > > > -Original Message- > > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 9:53 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > > > > also be sure to report right here is you touch any of the > > > > information in the > > > > ctx (using setters) > > > > > > > > marcf > > > > > > > > |-Original Message- > > > > |From: [EMAIL PROTECTED] > > > > |[mailto:[EMAIL PROTECTED]]On > > > > Behalf Of Dain > > > > |Sundstrom > > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > > |To: '[EMAIL PROTECTED]' > > > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > | > > > > | > > > > |> | The only way I can find to get a ctx for a pk > > > > |> |is from EntityInstanceInterceptor, and the only way to > > > get to the > > > > |> |EntityInstanceInterceptor is c
RE: [JBoss-dev] Where is everyone today?
Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:01 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Where is everyone today? > > > I would think you'd want to be out of the guts too, that just > seems a bit > too closely coupled with JBoss for the persistence manager. > Shouldn't the > CMP persistence manager be some type of layer on top (well > almost on top) > with a well defined interface? This should clearly tie in to > take advantage > of what the container can provide. > > I am definitely on the outside of JBoss though, so marc et al > are the people > to listen to. > > Cheers > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the transaction? Do I > > > need to lock the > > > context? What if one of the beans is removed? (the new remove > > > procedure for > > > relationships may handle this, but haven't implemented it yet) > > > > > > As you can tell this has given me a lot of concern. If > this is stuff I > > > shouldn't worry about, good. If I should worry, will it be > > > better to create > > > the new interceptor, thus reusing the code in the other > > > interceptors, or > > > will it be easier to handle the few special cases in the > > > persistence store? > > > > > > -dain > > > > > > > -Original Message- > > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 9:53 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > > > > also be sure to report right here is you touch any of the > > > > information in the > > > > ctx (using setters) > > > > > > > > marcf > > > > > > > > |-Original Message- > > > > |From: [EMAIL PROTECTED] > > > > |[mailto:[EMAIL PROTECTED]]On > > > > Behalf Of Dain > > > > |Sundstrom > > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > > |To: '[EMAIL PROTECTED]' > > > > |Subject: RE: [JBoss
RE: [JBoss-dev] Shutting down JBoss
Works great for me on Linux. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > Mulder > Sent: Friday, June 29, 2001 2:56 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Shutting down JBoss > > > On Fri, 29 Jun 2001, Bill Burke wrote: > > You can shut it down very easy from the JMX interface. Starting up is a > > different story. > > Last time I tried this, it unloaded all the beans and services, > but did not actually cause the JVM to exit, so JBoss was still taking a > boatload of system resources. Is there a "shutdown and exit" option now? > > Aaron > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shutting down JBoss
There are two classes for this: org.jboss.jmx.client.Stop org.jboss.Shutdown I don't know how well they work. Shutdown just invokes the shudown method on the Shutdown service which you can do using the JMS html adaptor. - Original Message - From: "Vinay Menon" <[EMAIL PROTECTED]> To: "Dev @ JBoss" <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 11:32 AM Subject: [JBoss-dev] Shutting down JBoss Alright, This might sound a bit naive but do we need a little simple gui that one can use to shut down JBoss or restart it? When you run JBoss on the command line in Unix as a background process [./run.sh&] it spawns loads of java processes that need to be killed. Is there a cleaner way to do this? Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where is everyone today?
I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, June 29, 2001 2:22 PM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-dev] Where is everyone today? > > > Is everyone on vacation? Is the list working? What-ever, doesn't really > matter. > > If any one is around today, and can reply to my message, I would greatly > appreciate it. I kind of need some guidance on the decision to create an > interceptor or not. I'm going to continue along the line that I > don't need > an interceptor (I can always add it later). > > If you all are on vacation, have a great time. > > -dain > > > -Original Message- > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 11:48 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > marc, > > > > Do you mean that I should be setting invoked, or something else? > > > > I got the bi-directional one-to-one (enforced integrity) > > working using the > > entity cache, but it gives me a bad feeling. In the this > > case, there may be > > up to 4 beans that need to be stored: > > > > before: > > a1--b1 > > a2--b2 > > > > a1.setB(b2) > > > > after: > > a1\ b1 > > a2 \b2 > > > > So, I hold onto up to three other contexts. When my store is > > called, I write > > my state and then store the other contexts (with their > > respective mangers). > > This won't cause extraneous writes as 'tuned updates' is always on. > > > > What is giving me the bad feeling is I have just cut out all > > of the work > > that is being done in the interceptors, specifically > > EntitySynchronizationInterceptor. For example, do I need to remove the > > context from the cache at the end of the transaction? Do I > > need to lock the > > context? What if one of the beans is removed? (the new remove > > procedure for > > relationships may handle this, but haven't implemented it yet) > > > > As you can tell this has given me a lot of concern. If this is stuff I > > shouldn't worry about, good. If I should worry, will it be > > better to create > > the new interceptor, thus reusing the code in the other > > interceptors, or > > will it be easier to handle the few special cases in the > > persistence store? > > > > -dain > > > > > -Original Message- > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 9:53 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > also be sure to report right here is you touch any of the > > > information in the > > > ctx (using setters) > > > > > > marcf > > > > > > |-Original Message- > > > |From: [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On > > > Behalf Of Dain > > > |Sundstrom > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > |To: '[EMAIL PROTECTED]' > > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > | > > > | > > > |> | The only way I can find to get a ctx for a pk > > > |> |is from EntityInstanceInterceptor, and the only way to > > get to the > > > |> |EntityInstanceInterceptor is container.invoke(mi). > > > |> > > > |> no no no it's in the cache, > > > |> > > > |> container.cache.get(id) (or something like that) > > > |> > > > |> marcf > > > |> > > > | > > > |YES! Thanks so much. I didn't want to write the interceptor. > > > |This is going > > > |to be way easier. I'm going to go code now. > > > | > > > |-dain > > > | > > > |___ > > > |Jboss-development mailing list > > > |[EMAIL PROTECTED] > > > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > __
RE: [JBoss-dev] Where is everyone today?
Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, June 29, 2001 2:22 PM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-dev] Where is everyone today? > > > Is everyone on vacation? Is the list working? What-ever, doesn't really > matter. > > If any one is around today, and can reply to my message, I would greatly > appreciate it. I kind of need some guidance on the decision to create an > interceptor or not. I'm going to continue along the line that I > don't need > an interceptor (I can always add it later). > > If you all are on vacation, have a great time. > > -dain > > > -Original Message- > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 11:48 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > marc, > > > > Do you mean that I should be setting invoked, or something else? > > > > I got the bi-directional one-to-one (enforced integrity) > > working using the > > entity cache, but it gives me a bad feeling. In the this > > case, there may be > > up to 4 beans that need to be stored: > > > > before: > > a1--b1 > > a2--b2 > > > > a1.setB(b2) > > > > after: > > a1\ b1 > > a2 \b2 > > > > So, I hold onto up to three other contexts. When my store is > > called, I write > > my state and then store the other contexts (with their > > respective mangers). > > This won't cause extraneous writes as 'tuned updates' is always on. > > > > What is giving me the bad feeling is I have just cut out all > > of the work > > that is being done in the interceptors, specifically > > EntitySynchronizationInterceptor. For example, do I need to remove the > > context from the cache at the end of the transaction? Do I > > need to lock the > > context? What if one of the beans is removed? (the new remove > > procedure for > > relationships may handle this, but haven't implemented it yet) > > > > As you can tell this has given me a lot of concern. If this is stuff I > > shouldn't worry about, good. If I should worry, will it be > > better to create > > the new interceptor, thus reusing the code in the other > > interceptors, or > > will it be easier to handle the few special cases in the > > persistence store? > > > > -dain > > > > > -Original Message- > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 9:53 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > also be sure to report right here is you touch any of the > > > information in the > > > ctx (using setters) > > > > > > marcf > > > > > > |-Original Message- > > > |From: [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On > > > Behalf Of Dain > > > |Sundstrom > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > |To: '[EMAIL PROTECTED]' > > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > | > > > | > > > |> | The only way I can find to get a ctx for a pk > > > |> |is from EntityInstanceInterceptor, and the only way to > > get to the > > > |> |EntityInstanceInterceptor is container.invoke(mi). > > > |> > > > |> no no no it's in the cache, > > > |> > > > |> container.cache.get(id) (or something like that) > > > |> > > > |> marcf > > > |> > > > | > > > |YES! Thanks so much. I didn't want to write the interceptor. > > > |This is going > > > |to be way easier. I'm going to go code now. > > > | > > > |-dain > > > | > > > |___ > > > |Jboss-development mailing list > > > |[EMAIL PROTECTED] > > > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED
RE: [JBoss-dev] Shutting down JBoss
On Fri, 29 Jun 2001, Bill Burke wrote: > You can shut it down very easy from the JMX interface. Starting up is a > different story. Last time I tried this, it unloaded all the beans and services, but did not actually cause the JVM to exit, so JBoss was still taking a boatload of system resources. Is there a "shutdown and exit" option now? Aaron ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shutting down JBoss
Vinay Menon wrote: > Alright, > > This might sound a bit naive but do we need a little simple > gui that one can use to shut down JBoss or restart it? When you run > JBoss on the command line in Unix as a background process [./run.sh&] it > spawns loads of java processes that need to be killed. Is there a > cleaner way to do this? > Those aren't processes, they're threads. You only need to kill the root java one (do a `ps axf` and you'll see what I mean by 'root'). As for the first issue, point a browser at http://myserver:8082/ and look at the shutdown mbean. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Shutting down JBoss
You can shut it down very easy from the JMX interface. Starting up is a different story. Bill -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay MenonSent: Friday, June 29, 2001 2:33 PMTo: Dev @ JBossSubject: [JBoss-dev] Shutting down JBoss Alright, This might sound a bit naive but do we need a little simple gui that one can use to shut down JBoss or restart it? When you run JBoss on the command line in Unix as a background process [./run.sh&] it spawns loads of java processes that need to be killed. Is there a cleaner way to do this? Vinay
[JBoss-dev] Shutting down JBoss
Alright, This might sound a bit naive but do we need a little simple gui that one can use to shut down JBoss or restart it? When you run JBoss on the command line in Unix as a background process [./run.sh&] it spawns loads of java processes that need to be killed. Is there a cleaner way to do this? Vinay
RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
Hi, yes, as far as I can tell from my unit tests xa works fine (I don't have Recover implemented yet, but should be easy). My unit tests have most features needed working, however as noted it doesn't yet work well with jboss. Also remember this is kind of pre-alpha, for instance it logs all low level db communication to System.out. It implements jca spi interfaces + jdbc Datasource and stuff you can get to from there (connections, statements, etc etc). I thought this would be most useful, if anyone wants a regular Driver interface maybe they can wrap the resource adapter. My original hope was to implement a combined jdbc connection - cci connection however this does not appear to be possible due to several methods of the same name and signature that throw different exceptions. Maybe sun could make SQLException subclass ResourceException. Any comments or help appreciated david jencks On 2001.06.29 11:40:09 -0400 Jay Walters wrote: > What does it do? Is it providing XA Connections for firebird? > > Cheers > > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 11:37 AM > To: [EMAIL PROTECTED] > Subject: RE: Isolation Levels was RE: [JBoss-dev] CVS update: > jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java > > > Hi, > > My firebird resource adapter is at firebird.sourceforge.net cvs under > client-java. I'm checking in my latest version which can build a rar > that > jboss deploys, it will create tables via jaws, but then crashes. It > works > ok with my test cases though! > > Any input on it gratefully appreciated. > > Thanks > david jencks > > On 2001.06.28 13:46:27 -0400 Carlos Cardenas wrote: > > Thanks for your replies, > > > > I would very much like to see David's resource > > adapter. I personally believe that it's the way to > > go. I believe we can work with the > > firebird/postgresql ( and maybe sapdb [too bad they > > don't have XA supp] in the future) to get the resource > > adapters (jca/jdbc) working and that way simplify and > > make consistent jboss' code. > > > > I am sure the same approach can be taken by some other > > people of our community when it comes to commercial > > databases like oracle, informix, etc (maybe payed?). > > > > thanks and have fun, CC > > > > --- Jay Walters <[EMAIL PROTECTED]> wrote: > > > My understanding of firebird is that it's a fraction > > > of the entire interbase > > > product missing many important features and tools. > > > (though it has XA > > > support?) > > > > > > On another note, I agree that Postgres is the only > > > other open source > > > database with XA support. I spent a bunch of time > > > poking around open source > > > databases and even my current favorite Sap DB > > > doesn't do XA. > > > > > > I am pretty sure that Postgres has a JDBC 2.0 XA > > > enabled driver, but I don't > > > think it's stable enough to be in the standard > > > distribution. > > > > > > Cheers > > > > > > -Original Message- > > > From: David Jencks > > > To: [EMAIL PROTECTED] > > > Sent: 6/27/01 8:05 PM > > > Subject: Re: Isolation Levels was RE: [JBoss-dev] > > > CVS update: > > > jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc > > > JDBCCommand.java > > > > > > Hi, > > > Thank you for the quote. > > > > > > > > > > > > > > > > By the way, does anyone know what is the best free > > > > database that supports XA (w/jdbc driver)? (I > > > love > > > > postgres, but the jdbc driver doesn't have XA > > > support > > > > (among other things), I don't even know if > > > postgres > > > > the database has it). Is interbase (the free and > > > > gratis version) it? > > > > > > > > > > > > > Interbase has supported 2pc since the 80's, in fact > > > may have been the > > > first > > > db to support it (they also invented blobs, original > > > meaning as in "blob > > > that ate cincinnatti", binary large object was a > > > marketers invention). > > > The > > > semantics are a little different from what xa likes, > > > but this can be > > > worked > > > around. > > > > > > > > > Interclient from borland or firebird does not > > > support xa, and suffers > > > from > > > ridiculous architecture. It is not worth trying to > > > add xa to it, imho. > > > > > > I am working on a pure java jca/jdbc-like resource > > > adapter for firebird > > > dialect 3 databases that does support xa. According > > > to my unit tests, > > > the > > > xa stuff works fine except for recovery ( not yet > > > implemented) and > > > queries > > > seem to work fine. I'm about to see if I can > > > package it up as a rar and > > > use it with jboss. > > > > > > david jencks > > > > > > > Hope this helps to the discussion on Isolation > > > levels, > > > > > > > > > > > > Thanks, CC > > > > > > > > __ > > > > Do You Yahoo!? > > > > Get personalized email addresses from Yahoo! Mail > > > > http://personal.mail.yahoo.com/ > > > >
[JBoss-dev] Where is everyone today?
Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 28, 2001 11:48 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > marc, > > Do you mean that I should be setting invoked, or something else? > > I got the bi-directional one-to-one (enforced integrity) > working using the > entity cache, but it gives me a bad feeling. In the this > case, there may be > up to 4 beans that need to be stored: > > before: > a1--b1 > a2--b2 > > a1.setB(b2) > > after: > a1\ b1 > a2 \b2 > > So, I hold onto up to three other contexts. When my store is > called, I write > my state and then store the other contexts (with their > respective mangers). > This won't cause extraneous writes as 'tuned updates' is always on. > > What is giving me the bad feeling is I have just cut out all > of the work > that is being done in the interceptors, specifically > EntitySynchronizationInterceptor. For example, do I need to remove the > context from the cache at the end of the transaction? Do I > need to lock the > context? What if one of the beans is removed? (the new remove > procedure for > relationships may handle this, but haven't implemented it yet) > > As you can tell this has given me a lot of concern. If this is stuff I > shouldn't worry about, good. If I should worry, will it be > better to create > the new interceptor, thus reusing the code in the other > interceptors, or > will it be easier to handle the few special cases in the > persistence store? > > -dain > > > -Original Message- > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 9:53 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > also be sure to report right here is you touch any of the > > information in the > > ctx (using setters) > > > > marcf > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On > > Behalf Of Dain > > |Sundstrom > > |Sent: Thursday, June 28, 2001 9:45 PM > > |To: '[EMAIL PROTECTED]' > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > | > > | > > |> | The only way I can find to get a ctx for a pk > > |> |is from EntityInstanceInterceptor, and the only way to > get to the > > |> |EntityInstanceInterceptor is container.invoke(mi). > > |> > > |> no no no it's in the cache, > > |> > > |> container.cache.get(id) (or something like that) > > |> > > |> marcf > > |> > > | > > |YES! Thanks so much. I didn't want to write the interceptor. > > |This is going > > |to be way easier. I'm going to go code now. > > | > > |-dain > > | > > |___ > > |Jboss-development mailing list > > |[EMAIL PROTECTED] > > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss_2_4.dtd
User: starksm Date: 01/06/29 11:13:14 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jboss_2_4.dtd Log: Update container-pool-conf content model to: ((MaximumSize , MinimumSize) | Synchronized) and add Synchronized element Revision ChangesPath No revision No revision 1.1.2.4 +19 -3 jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd Index: jboss_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd,v retrieving revision 1.1.2.3 retrieving revision 1.1.2.4 diff -u -r1.1.2.3 -r1.1.2.4 --- jboss_2_4.dtd 2001/06/22 22:52:30 1.1.2.3 +++ jboss_2_4.dtd 2001/06/29 18:13:14 1.1.2.4 @@ -85,7 +85,7 @@ 3- the deployer can specify runtime jndi names for resource managers. --> - + - + + + + + - + + + +
Re: [JBoss-dev] jboss_2_4.dtd - take 2
I updated the dtd in main and 2.4 - Original Message - From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Scott M Stark" <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 3:06 AM Subject: [JBoss-dev] jboss_2_4.dtd - take 2 > Scott > > there is an error in the jboss 2.4 dtd. > > The SingletonStatelessSessionInstancePool class in org.jboss.ejb.plugins > has a boolean attribute isSynchronized that is set by an XML element > 'Synchronized' in the container-pool-conf. > > So :- > > > > needs to be > > > > and a definition for Synchronized added. > > > > > thanks > > Mike S-R > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss_2_4.dtd
User: starksm Date: 01/06/29 11:00:34 Modified:src/resources/org/jboss/metadata jboss_2_4.dtd Log: Update container-pool-conf content model to: ((MaximumSize , MinimumSize) | Synchronized) and add Synchronized element Revision ChangesPath 1.5 +19 -3 jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd Index: jboss_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jboss_2_4.dtd 2001/06/22 22:52:01 1.4 +++ jboss_2_4.dtd 2001/06/29 18:00:33 1.5 @@ -85,7 +85,7 @@ 3- the deployer can specify runtime jndi names for resource managers. --> - + - + + + + + - + + + +
[JBoss-dev] RE: JBoss Linux startup scripts
I just used the script somebody linked to the documentation of jBoss. So which variables have to be set correctly? I set JBOSS_HOME and TOMCAT_HOME correctly, otherwise, the stuff wouldn't start at all. What else do i have to set. I am using, like I said already, the jboss script in init.d and the go.sh script in the jboss/bin directory. Mit freundlichen Gruessen / best regards Markus M. May Think4You AG Hanauer Landstrasse 135-137 60314 Frankfurt / Main T. +49 69 2424 18 14 F. +49 69 2424 18 60 mailto:[EMAIL PROTECTED] http://www.think4you.com ++ Mit eProcurement Gewinne einkaufen! In Frankfurt und München finden im August und September Info-Workshops zum Thema eProcurement mit unserem Partner Openshop statt! Informieren Sie sich bei uns unter Mailto:[EMAIL PROTECTED] ++
Re: [JBoss-dev] MDB problem with latest CVS?
On 27 Jun, Jason Dillon wrote: > Hey, I had to stop playing with build systems and get some actual work done. > I was finishing up integrating the JMS RA support, so my application has > better JMS/EJB TX integration and I started getting messages like the > snippet below. The application seems to behave as normal, but I am > concerned that this might cause problems underload. > > This seems to happen quite frequently. I breifly looked into the exception, > but it is not obvious to me what might be wrong, or even if there is > something wrong at all. This is the failsafe code in the invoker doing it's work. If you remote server (where the destinations are) was down, there is nothin g to worry about. If not, it is probably a bug in JBossMQ (take it on the JBossMQ mailinglist). //Peter > > On a related note could someone explain what the difference between UIL and > OIL is? > > > java.io.EOFException > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > Container factory [ConnectionReceiverOIL Server] WARN - MDB lost connection > to provider > Container factory [ConnectionReceiverOIL Server] INFO - MDB Trying to > reconnect... > at > >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > at java.lang.Thread.run(Thread.java:484) > Container factory [ConnectionReceiverOIL Server] DEBUG - Destroying > JMSContainerInvoker > Container factory [ConnectionReceiverOIL Server] DEBUG - Clearing 15 from > ServerSessionPool > Container factory [ConnectionReceiverOIL Server] DEBUG - Got destination > type Queue > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > java.io.EOFException > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > at java.io.ObjectInputStream.readByte(ObjectInputStream.java:1908) > at > >org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:111) > at java.lang.Thread.run(Thread.java:484) > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Setting listener > for session > Container factory [ConnectionReceiverOIL Server] DEBUG - Server Session pool > set up > Container factory [ConnectionReceiverOIL Server] DEBUG - Queue > connectionConsumer set up > Container factory [ConnectionReceiverOIL Server] DEBUG - Starting > JMSContainerInvoker > Container factory [ConnectionReceiverOIL Server] INFO - OK - reconnected > > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
What does it do? Is it providing XA Connections for firebird? Cheers -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 11:37 AM To: [EMAIL PROTECTED] Subject: RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java Hi, My firebird resource adapter is at firebird.sourceforge.net cvs under client-java. I'm checking in my latest version which can build a rar that jboss deploys, it will create tables via jaws, but then crashes. It works ok with my test cases though! Any input on it gratefully appreciated. Thanks david jencks On 2001.06.28 13:46:27 -0400 Carlos Cardenas wrote: > Thanks for your replies, > > I would very much like to see David's resource > adapter. I personally believe that it's the way to > go. I believe we can work with the > firebird/postgresql ( and maybe sapdb [too bad they > don't have XA supp] in the future) to get the resource > adapters (jca/jdbc) working and that way simplify and > make consistent jboss' code. > > I am sure the same approach can be taken by some other > people of our community when it comes to commercial > databases like oracle, informix, etc (maybe payed?). > > thanks and have fun, CC > > --- Jay Walters <[EMAIL PROTECTED]> wrote: > > My understanding of firebird is that it's a fraction > > of the entire interbase > > product missing many important features and tools. > > (though it has XA > > support?) > > > > On another note, I agree that Postgres is the only > > other open source > > database with XA support. I spent a bunch of time > > poking around open source > > databases and even my current favorite Sap DB > > doesn't do XA. > > > > I am pretty sure that Postgres has a JDBC 2.0 XA > > enabled driver, but I don't > > think it's stable enough to be in the standard > > distribution. > > > > Cheers > > > > -Original Message- > > From: David Jencks > > To: [EMAIL PROTECTED] > > Sent: 6/27/01 8:05 PM > > Subject: Re: Isolation Levels was RE: [JBoss-dev] > > CVS update: > > jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc > > JDBCCommand.java > > > > Hi, > > Thank you for the quote. > > > > > > > > > > > By the way, does anyone know what is the best free > > > database that supports XA (w/jdbc driver)? (I > > love > > > postgres, but the jdbc driver doesn't have XA > > support > > > (among other things), I don't even know if > > postgres > > > the database has it). Is interbase (the free and > > > gratis version) it? > > > > > > > > > Interbase has supported 2pc since the 80's, in fact > > may have been the > > first > > db to support it (they also invented blobs, original > > meaning as in "blob > > that ate cincinnatti", binary large object was a > > marketers invention). > > The > > semantics are a little different from what xa likes, > > but this can be > > worked > > around. > > > > > > Interclient from borland or firebird does not > > support xa, and suffers > > from > > ridiculous architecture. It is not worth trying to > > add xa to it, imho. > > > > I am working on a pure java jca/jdbc-like resource > > adapter for firebird > > dialect 3 databases that does support xa. According > > to my unit tests, > > the > > xa stuff works fine except for recovery ( not yet > > implemented) and > > queries > > seem to work fine. I'm about to see if I can > > package it up as a rar and > > use it with jboss. > > > > david jencks > > > > > Hope this helps to the discussion on Isolation > > levels, > > > > > > > > > Thanks, CC > > > > > > __ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail > > > http://personal.mail.yahoo.com/ > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Isolation Levels was RE: [JBoss-dev] CVS update: jboss/src/ma in/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
Hi, My firebird resource adapter is at firebird.sourceforge.net cvs under client-java. I'm checking in my latest version which can build a rar that jboss deploys, it will create tables via jaws, but then crashes. It works ok with my test cases though! Any input on it gratefully appreciated. Thanks david jencks On 2001.06.28 13:46:27 -0400 Carlos Cardenas wrote: > Thanks for your replies, > > I would very much like to see David's resource > adapter. I personally believe that it's the way to > go. I believe we can work with the > firebird/postgresql ( and maybe sapdb [too bad they > don't have XA supp] in the future) to get the resource > adapters (jca/jdbc) working and that way simplify and > make consistent jboss' code. > > I am sure the same approach can be taken by some other > people of our community when it comes to commercial > databases like oracle, informix, etc (maybe payed?). > > thanks and have fun, CC > > --- Jay Walters <[EMAIL PROTECTED]> wrote: > > My understanding of firebird is that it's a fraction > > of the entire interbase > > product missing many important features and tools. > > (though it has XA > > support?) > > > > On another note, I agree that Postgres is the only > > other open source > > database with XA support. I spent a bunch of time > > poking around open source > > databases and even my current favorite Sap DB > > doesn't do XA. > > > > I am pretty sure that Postgres has a JDBC 2.0 XA > > enabled driver, but I don't > > think it's stable enough to be in the standard > > distribution. > > > > Cheers > > > > -Original Message- > > From: David Jencks > > To: [EMAIL PROTECTED] > > Sent: 6/27/01 8:05 PM > > Subject: Re: Isolation Levels was RE: [JBoss-dev] > > CVS update: > > jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc > > JDBCCommand.java > > > > Hi, > > Thank you for the quote. > > > > > > > > > > > By the way, does anyone know what is the best free > > > database that supports XA (w/jdbc driver)? (I > > love > > > postgres, but the jdbc driver doesn't have XA > > support > > > (among other things), I don't even know if > > postgres > > > the database has it). Is interbase (the free and > > > gratis version) it? > > > > > > > > > Interbase has supported 2pc since the 80's, in fact > > may have been the > > first > > db to support it (they also invented blobs, original > > meaning as in "blob > > that ate cincinnatti", binary large object was a > > marketers invention). > > The > > semantics are a little different from what xa likes, > > but this can be > > worked > > around. > > > > > > Interclient from borland or firebird does not > > support xa, and suffers > > from > > ridiculous architecture. It is not worth trying to > > add xa to it, imho. > > > > I am working on a pure java jca/jdbc-like resource > > adapter for firebird > > dialect 3 databases that does support xa. According > > to my unit tests, > > the > > xa stuff works fine except for recovery ( not yet > > implemented) and > > queries > > seem to work fine. I'm about to see if I can > > package it up as a rar and > > use it with jboss. > > > > david jencks > > > > > Hope this helps to the discussion on Isolation > > levels, > > > > > > > > > Thanks, CC > > > > > > __ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail > > > http://personal.mail.yahoo.com/ > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/examples/org/jboss/docs/javamail Mailer.java MailerBean.java MailerHome.java MailerServlet.java application.xml build.xml ejb-jar.xml home.html jboss-web.xml jboss.xml web.xml
User: gropi
Date: 01/06/29 03:44:56
Added: src/examples/org/jboss/docs/javamail Mailer.java
MailerBean.java MailerHome.java MailerServlet.java
application.xml build.xml ejb-jar.xml home.html
jboss-web.xml jboss.xml web.xml
Log:
JBoss 2.2.2 compliance updates by Francois Charoy
Revision ChangesPath
1.1 manual/src/examples/org/jboss/docs/javamail/Mailer.java
Index: Mailer.java
===
package org.jboss.docs.javamail;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.EJBObject;
public interface Mailer extends EJBObject {
public abstract void sendMail(String address) throws java.rmi.RemoteException;
}
1.1 manual/src/examples/org/jboss/docs/javamail/MailerBean.java
Index: MailerBean.java
===
package org.jboss.docs.javamail;
import java.util.Date;
import javax.ejb.SessionBean;
import javax.naming.InitialContext;
import javax.mail.Session;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.InternetAddress;
import javax.mail.Transport;
import javax.mail.Address;
import javax.mail.Message;
import javax.rmi.PortableRemoteObject;
public class MailerBean implements SessionBean {
public void ejbCreate() {}
public void ejbPostCreate() {}
public void sendMail(String address) throws java.rmi.RemoteException {
Session session = null;
try {
session = (Session)PortableRemoteObject.narrow(new
InitialContext().lookup("java:Mail"), Session.class);
} catch (javax.naming.NamingException e) {
e.printStackTrace();
}
try {
MimeMessage m = new MimeMessage(session);
m.setFrom();
Address[] to = new InternetAddress[] {
new InternetAddress(address)
};
m.setRecipients(Message.RecipientType.TO, to);
m.setSubject("JavaMail Test");
m.setSentDate(new Date());
m.setContent("Test from inside EJB Using JBoss",
"text/plain");
Transport.send(m);
} catch (javax.mail.MessagingException e) {
e.printStackTrace();
}
}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbRemove() {}
public void setSessionContext(javax.ejb.SessionContext ec) {}
}
1.1 manual/src/examples/org/jboss/docs/javamail/MailerHome.java
Index: MailerHome.java
===
package org.jboss.docs.javamail;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
import java.rmi.RemoteException;
public interface MailerHome extends EJBHome
{
public abstract Mailer create() throws CreateException, RemoteException;
}
1.1 manual/src/examples/org/jboss/docs/javamail/MailerServlet.java
Index: MailerServlet.java
===
package org.jboss.docs.javamail;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Hashtable;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.jboss.docs.javamail.Mailer;
import org.jboss.docs.javamail.MailerHome;
/**
* This Servlet provides a user interface to an Enterprise Java Bean.
* The example EJB described in the jBoss documentation at
* http://jboss.org/ sends an e-mail to the given address
* This servlet will call the Mailer EJB, passing it a the
* email address.
*/
public class MailerServlet extends HttpServlet
{
private MailerHome mailerHome = null;
/** Looks up the MailerHome interface and saves it for use in
doGet().
*/
public void init() throws ServletException
{
try
{
// Get a naming context
InitialContext jndiContext = new InitialContext();
// Get a reference to the Interest Bean
Object ref = jndiContext.lookup("Mailer");
// Get a reference from this to the Bean's Home interface
mailerHome = (MailerHome) PortableRemoteObject.narrow(ref,
MailerHome.class);
}
catch(Exception e)
{
throw new ServletException("Failed to lookup Mailer", e);
}
}
/**
*/
public void doPost(HttpServletRequest request, HttpServletResponse res
[JBoss-dev] CVS update: manual/src/examples/build build.xml
User: gropi Date: 01/06/29 03:44:56 Modified:src/examples/build build.xml Log: JBoss 2.2.2 compliance updates by Francois Charoy Revision ChangesPath 1.10 +161 -139 manual/src/examples/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/manual/src/examples/build/build.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- build.xml 2001/06/26 22:23:15 1.9 +++ build.xml 2001/06/29 10:44:55 1.10 @@ -1,139 +1,161 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs howtojavamail.xml
User: gropi Date: 01/06/29 03:44:55 Modified:src/docs howtojavamail.xml Log: JBoss 2.2.2 compliance updates by Francois Charoy Revision ChangesPath 1.5 +208 -226 manual/src/docs/howtojavamail.xml Index: howtojavamail.xml === RCS file: /cvsroot/jboss/manual/src/docs/howtojavamail.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- howtojavamail.xml 2001/05/17 20:31:29 1.4 +++ howtojavamail.xml 2001/06/29 10:44:55 1.5 @@ -1,226 +1,208 @@ - - - Using JavaMail in JBoss - - - Michel - de Groot - - [EMAIL PROTECTED] - - - Introduction - JBoss has a built-in implementation of the JavaMail API. You can use this -service from inside and outside EJBs. We -describe here how to use the service. - - - Installation - - - - - Edit - a) Replace the User and Password attributes values with the user name and -password used to connect to your - mail server. You can find these values in your mail program. The mail -service will use this account to send mails, - so be sure that this mail account works properly (test it with your mail -program for example). - b) Replace the ConfigurationFile attribute value with the file containing -the mail settings. Default is - "mail.properties", which is also in the - c) Replace the JNDIName attribute value with the JNDI name for your mail -session. The default is "Mail". This - JNDI name will be used in jboss.xml to identify the resource. This is -explained in more detail in step 4. - - - Edit the mail properties file you identified in step 1b. By -default, this is - Edit the following lines: - - mail.user = sa005697// the user to connect with; same as in step 1a - mail.pop3.host = pop3.wolmail.nl// the pop host to store the mail -on - mail.smtp.host = smtp.wolmail.nl// the smtp host to send the mail -to - mail.from = [EMAIL PROTECTED] // the 'from' field that is -filled in by default in e-mails - - - - - You can find most value in your mail program. You might want to inspect -the JavaMail specification for more - details. - - - - The last line, mail.debug, should be set to 'true' for now. This will -provide you with verbose debugging - information. Once you have everything running correctly, you can set it -to false. - - - - Edit the ejb-jar.xml of the EJB that uses the mail service. -In your EJB, specify a - - - This will tell the EJB container that the EJB uses a javax.mail.Session -resource named mail/MyMail and that - authorization is container managed. - - You can change the name if you like, but be sure to use the same name in -step 6, in the code example. - - - - Edit the jboss.xml of the EJB that uses the mail service. -If you don't have this file, create it and place it in the - same directory as the ejb-jar.xml of the EJB. This file is JBoss specific -and tells JBoss how to map the mail - resource to the mail service provider in JBoss. - - In this file, specify a - - The name that you specify here is the name that you specified in step 3. -The JNDI name that you specify here is - the name that you specified in step 1c. - - - - Edit the bin/run.bat file of your JBoss - installation. Include ../lib/ext/mail.jar and ../lib/ext/activation.jar - in the classpath explicitly. This assumes that you start JBoss from the bin - directory. If not, you should modify the paths - to the jars accordingly. Make sure you list mail.jar before activation.jar - or you may get cryptic errors like 'no object DCH for MIME type - text/plain'. - - TO BE IMPROVED: This step should not be required; both ma
[JBoss-dev] jboss_2_4.dtd - take 2
Scott there is an error in the jboss 2.4 dtd. The SingletonStatelessSessionInstancePool class in org.jboss.ejb.plugins has a boolean attribute isSynchronized that is set by an XML element 'Synchronized' in the container-pool-conf. So :- needs to be and a definition for Synchronized added. thanks Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss_2_4.dtd
Scott there is an error in the jboss 2.4 dtd. The SingletonStatelessSessionInstancePool class in org.jboss.ejb.plugins has a boolean attribute isSynchronized that is set by an XML element 'Synchronized' in the container-pool-conf. So :- needs to be and a definition for Synchronized added. thanks Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Query on the JBoss versions of j2ee jars...
Hi, I was reading the critique of JSR47: http://jakarta.apache.org/log4j/docs/critique.html and noticed this paragraph, in the "Other Differences" section; " Note that any third-party implementation using the java.* or javax.* namespaces violates Sun's trademark on Java. Without explicit permission from Sun, such software remains under the threat of litigation. " So - I presume JBoss got explicit permission from Sun for its own version of the jars? Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
