[JBoss-dev] [ jboss-Bugs-554535 ] Oracle BLOB and byte array
Bugs item #554535, was opened at 2002-05-10 17:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=554535group_id=22866 Category: JBossCMP Group: v2.4 (stable) Status: Open Resolution: Accepted Priority: 5 Submitted By: Niall O'Sullivan (nosullivan) Assigned to: Dain Sundstrom (dsundstrom) Summary: Oracle BLOB and byte array Initial Comment: Re-submiting a bug that was never fixed and closed. The Orginial problem was [ 434620 ] Oracle BLOB and byte array The Conclusion was If this problem persists with JBoss 2.4 or 3 then please report it again. JBoss 2.2 is not supported anymore. I can confirm that this is still a bug in 2.4. JBoss: JBoss-2.4.4_Jetty-3.1.7-1 OS: Windows 2K and Windows NT JDK: 1.4 DB: Oracle 8.1.6 The suggested fix in [434620] works for me but hasn't been integrated into jboss and presumably hasn't been tested against other DBs. -- Comment By: Cezary Zawadka (czawadka) Date: 2002-06-18 12:26 Message: Logged In: YES user_id=311672 Is this working? I've got following exception with oracle driver (8.1.7): java.lang.ClassCastException: org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob at oracle.jdbc.driver.OraclePreparedStatement.setBlob (OraclePreparedStatement.java:1446) at org.jboss.resource.adapter.jdbc.local.LocalPreparedStatement.set Blob(LocalPreparedStatement.java:680) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter (JDBCUtil.java:220) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid ge.setArgumentParameters (JDBCAbstractCMPFieldBridge.java:283) In oracle driver (OraclePreparedStatement) is: public synchronized void setBlob(int i, Blob blob) throws SQLException { setBLOB(i, (BLOB)blob); } The same code is in the current release (9.2.0.1) of oracle driver. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-16 22:20 Message: Logged In: YES user_id=251431 This patch has been integrated into JBossCMP (HEAD) with some slight modifications (see original patch for details). I NEED YOU TO TEST THIS (IN HEAD) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=554535group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-569077 ] read-ahead issues
Bugs item #569077, was opened at 2002-06-14 11:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569077group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Newcomb (mnewcomb) Assigned to: Dain Sundstrom (dsundstrom) Summary: read-ahead issues Initial Comment: I'm submitting this to keep track of some issues that have arisen with the rewrite of the read-ahead code. Most of the problems I am encountering have to deal with very large sets of data (to the tune of 10k+ entity beans). I'm just gonna give a quick summary of the problems, but if you are interested in the details, I can forward the e-mail thread between Dain and myself discussing the problems. Summary: 1. Replacing FinderResults with a List indirectly causes a large amount of compares to occur when working with 'listMap' because FinderResults.equals was just doing identity comparison as opposed to List.equals which starts walking the list comparing values. 2. Relationship read-aheads and finder read-aheads share the same 'listMap'. So, if a bean is found in a read-ahead and then in a relationship, the results keep getting replaced with the last accessed one. Michael -- Comment By: Michael Newcomb (mnewcomb) Date: 2002-06-18 08:37 Message: Logged In: YES user_id=382427 Forget about the first patch. Here is a new patch which solves the performance problem. When finder results are added to the cache, dereferenced results are not longer resolved by walking the entire listMap. Instead, each PK in the dereferenced list is looked up to see if it references the list. The first key that still references the list cancels the lists dereferency (I know that is not a word). Michael -- Comment By: Michael Newcomb (mnewcomb) Date: 2002-06-17 13:08 Message: Logged In: YES user_id=382427 Ok. Here are the major things I did. 1. JDBCStoreManager used to just have one ReadAheadCache, now it has getEntityReadAheadCache and getRelatedReadAheadCache. All entity-based read-ahead finder results are placed in the EntityReadAheadCache and all relation-based read-ahead finder results are placed in the RelatedReadAheadCache. 2. I removed all references to the ListCache. I fail to see how the cache is getting used... All finder results were being put into the 'listMap' and therefore even if they were aged out of the 'listCache' they would still be in the 'listMap'. Furthermore, the cache was never accessed. The change to the JDBCStoreManager required a few changes to other classes: JDBCAbstractQueryCommand.java, JDBCLoadEntityCommand.java, JDBCLoadRelationCommand.java, JDBCRemoveEntityCommand.java, JDBCCMRFieldBridge.java. -- Comment By: Michael Newcomb (mnewcomb) Date: 2002-06-17 07:23 Message: Logged In: YES user_id=382427 Sure. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-16 15:42 Message: Logged In: YES user_id=251431 You gonna work on this Micheal? =) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569077group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
Initial testing in Oracle 9i was not promising (using the latest driver (Oracle JDBC Driver version - 9.0.2.0.0): 2002-06-18 23:39:05,843 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.SimpleEJB] Executing SQL: UPDATE SIMPLE SET booleanPrimitive=?, booleanObject=?, bytePrimitive=?, byteObject=?, shortPrimitive=?, shortObject=?, integerPrimitive=?, integerObject=?, longPrimitive=?, longObject=?, floatPrimitive=?, floatObject=?, doublePrimitive=?, doubleObject=?, stringValue=?, utilDateValue=?, sqlDateValue=?, timeValue=?, timestampValue=?, bigDecimalValue=?, byteArrayValue=?, objectValue=? WHERE id=? 2002-06-18 23:39:05,848 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Set parameter: index=1, jdbcType=BIT, value=true 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Set parameter: index=2, jdbcType=BIT, value=false 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Set parameter: index=3, jdbcType=TINYINT, value=11 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Set parameter: index=4, jdbcType=TINYINT, value=22 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Set parameter: index=5, jdbcType=SMALLINT, value=33 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Set parameter: index=6, jdbcType=SMALLINT, value=44 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Set parameter: index=7, jdbcType=INTEGER, value=55 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Set parameter: index=8, jdbcType=INTEGER, value=66 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Set parameter: index=9, jdbcType=BIGINT, value=77 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Set parameter: index=10, jdbcType=BIGINT, value=88 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Set parameter: index=11, jdbcType=REAL, value=11.11 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Set parameter: index=12, jdbcType=REAL, value=22.22 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive] Set parameter: index=13, jdbcType=DOUBLE, value=33.33 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject] Set parameter: index=14, jdbcType=DOUBLE, value=44.44 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue] Set parameter: index=15, jdbcType=VARCHAR, value=test string value 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue] Set parameter: index=16, jdbcType=TIMESTAMP, value=Thu Jan 01 11:00:01 EST 1970 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.sqlDateValue] Set parameter: index=17, jdbcType=DATE, value=1981-05-05 2002-06-18 23:39:05,857 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timeValue] Set parameter: index=18, jdbcType=TIME, value=22:33:44 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timestampValue] Set parameter: index=19, jdbcType=TIMESTAMP, value=1970-01-01 11:00:04.444 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bigDecimalValue] Set parameter: index=20, jdbcType=DECIMAL, value=12345678 2002-06-18 23:39:05,859 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteArrayValue] Set parameter: index=21, jdbcType=BLOB, value=[B@2d54c5 2002-06-18 23:39:05,861 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: simple javax.ejb.EJBException: Store failed; CausedByException is: org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute (JDBCStoreEntityCommand.java:94) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity (JDBCStoreManager.java:586) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:458) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.storeEntity( CachedConnectionInterceptor.java:388) at
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
Crap. I bet the check for a specific Oracle type in the new drivers. I'll switch it back to JAVA_OBJECT for 9i. Can someone please test Oracle 8? If it doesn't work with either one, I'm going to delete the new code. Does anyone want to work on the real fix for this? I can walk you through what needs to be changed. -dain Stephen Coy wrote: Initial testing in Oracle 9i was not promising (using the latest driver (Oracle JDBC Driver version - 9.0.2.0.0): 2002-06-18 23:39:05,843 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.SimpleEJB] Executing SQL: UPDATE SIMPLE SET booleanPrimitive=?, booleanObject=?, bytePrimitive=?, byteObject=?, shortPrimitive=?, shortObject=?, integerPrimitive=?, integerObject=?, longPrimitive=?, longObject=?, floatPrimitive=?, floatObject=?, doublePrimitive=?, doubleObject=?, stringValue=?, utilDateValue=?, sqlDateValue=?, timeValue=?, timestampValue=?, bigDecimalValue=?, byteArrayValue=?, objectValue=? WHERE id=? 2002-06-18 23:39:05,848 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Set parameter: index=1, jdbcType=BIT, value=true 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Set parameter: index=2, jdbcType=BIT, value=false 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Set parameter: index=3, jdbcType=TINYINT, value=11 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Set parameter: index=4, jdbcType=TINYINT, value=22 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Set parameter: index=5, jdbcType=SMALLINT, value=33 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Set parameter: index=6, jdbcType=SMALLINT, value=44 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Set parameter: index=7, jdbcType=INTEGER, value=55 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Set parameter: index=8, jdbcType=INTEGER, value=66 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Set parameter: index=9, jdbcType=BIGINT, value=77 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Set parameter: index=10, jdbcType=BIGINT, value=88 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Set parameter: index=11, jdbcType=REAL, value=11.11 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Set parameter: index=12, jdbcType=REAL, value=22.22 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive] Set parameter: index=13, jdbcType=DOUBLE, value=33.33 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject] Set parameter: index=14, jdbcType=DOUBLE, value=44.44 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue] Set parameter: index=15, jdbcType=VARCHAR, value=test string value 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue] Set parameter: index=16, jdbcType=TIMESTAMP, value=Thu Jan 01 11:00:01 EST 1970 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.sqlDateValue] Set parameter: index=17, jdbcType=DATE, value=1981-05-05 2002-06-18 23:39:05,857 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timeValue] Set parameter: index=18, jdbcType=TIME, value=22:33:44 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timestampValue] Set parameter: index=19, jdbcType=TIMESTAMP, value=1970-01-01 11:00:04.444 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bigDecimalValue] Set parameter: index=20, jdbcType=DECIMAL, value=12345678 2002-06-18 23:39:05,859 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteArrayValue] Set parameter: index=21, jdbcType=BLOB, value=[B@2d54c5 2002-06-18 23:39:05,861 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: simple javax.ejb.EJBException: Store failed; CausedByException is: org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob at
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
I've done some more poking at this, and modified JDBCUtil.setParameter as follows: // // Binary types need to be converted to a byte array and set // if(isBinaryJDBCType(jdbcType)) { byte[] bytes = convertObjectToByteArray(value); if (bytes.length 2000 jdbcType != Types.BLOB) { // it's more efficient to use setBinaryStream for large // streams, and causes problems if not done on some DBMS // implementations ps.setBytes(index, bytes); } else { InputStream in = null; try { in = new ByteArrayInputStream(bytes); ps.setBinaryStream(index, in, bytes.length); } finally { safeClose(in); } } return; ie. Forget about the ByteArrayBlob class. This works fine when writing to the database. However, reading the data back fails: 2002-06-18 23:59:20,671 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.SimpleEJB] Executing SQL: SELECT booleanPrimitive, booleanObject, bytePrimitive, byteObject, shortPrimitive, shortObject, integerPrimitive, integerObject, longPrimitive, longObject, floatPrimitive, floatObject, doublePrimitive, doubleObject, stringValue, utilDateValue, sqlDateValue, timeValue, timestampValue, bigDecimalValue, byteArrayValue, objectValue FROM SIMPLE WHERE (id=?) 2002-06-18 23:59:20,680 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.id] Set parameter: index=1, jdbcType=VARCHAR, value=simple 2002-06-18 23:59:20,707 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Get result: index=1, javaType=boolean, Simple, value=true 2002-06-18 23:59:20,709 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Get result: index=2, javaType=java.lang.Boolean, Simple, value=false 2002-06-18 23:59:20,713 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Get result: index=3, javaType=byte, Simple, value=11 2002-06-18 23:59:20,715 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Get result: index=4, javaType=java.lang.Byte, Simple, value=22 2002-06-18 23:59:20,717 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Get result: index=5, javaType=short, Simple, value=33 2002-06-18 23:59:20,718 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Get result: index=6, javaType=java.lang.Short, Simple, value=44 2002-06-18 23:59:20,720 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Get result: index=7, javaType=int, Simple, value=55 2002-06-18 23:59:20,726 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Get result: index=8, javaType=java.lang.Integer, Simple, value=66 2002-06-18 23:59:20,728 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Get result: index=9, javaType=long, Simple, value=77 2002-06-18 23:59:20,730 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Get result: index=10, javaType=java.lang.Long, Simple, value=88 2002-06-18 23:59:20,731 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Get result: index=11, javaType=float, Simple, value=11.11 2002-06-18 23:59:20,733 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Get result: index=12, javaType=java.lang.Float, Simple, value=22.22 2002-06-18 23:59:20,735 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive] Get result: index=13, javaType=double, Simple, value=33.33 2002-06-18 23:59:20,738 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject] Get result: index=14, javaType=java.lang.Double, Simple, value=44.44 2002-06-18 23:59:20,740 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue] Get result: index=15, javaType=java.lang.String, Simple, value=test string value 2002-06-18 23:59:20,742 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue] Get result: index=16, javaType=java.util.Date, Simple, value=1970-01-01 11:00:01.111 2002-06-18 23:59:20,744 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.sqlDateValue] Get result: index=17, javaType=java.sql.Date, Simple, value=1981-05-05 2002-06-18 23:59:20,746 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timeValue] Get result: index=18, javaType=java.sql.Time, Simple, value=22:33:44 2002-06-18 23:59:20,748 TRACE
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
This is the way the code was before I integrated the Oracle BLOB patch. The problem is the serialized stream is being truncated to 4000 bytes. I just got an email from someone willing to work on implementing correct BLOB handling. I'd still like someone to try this in Oracle 8. -dain Stephen Coy wrote: I've done some more poking at this, and modified JDBCUtil.setParameter as follows: // // Binary types need to be converted to a byte array and set // if(isBinaryJDBCType(jdbcType)) { byte[] bytes = convertObjectToByteArray(value); if (bytes.length 2000 jdbcType != Types.BLOB) { // it's more efficient to use setBinaryStream for large // streams, and causes problems if not done on some DBMS // implementations ps.setBytes(index, bytes); } else { InputStream in = null; try { in = new ByteArrayInputStream(bytes); ps.setBinaryStream(index, in, bytes.length); } finally { safeClose(in); } } return; ie. Forget about the ByteArrayBlob class. This works fine when writing to the database. However, reading the data back fails: 2002-06-18 23:59:20,671 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.SimpleEJB] Executing SQL: SELECT booleanPrimitive, booleanObject, bytePrimitive, byteObject, shortPrimitive, shortObject, integerPrimitive, integerObject, longPrimitive, longObject, floatPrimitive, floatObject, doublePrimitive, doubleObject, stringValue, utilDateValue, sqlDateValue, timeValue, timestampValue, bigDecimalValue, byteArrayValue, objectValue FROM SIMPLE WHERE (id=?) 2002-06-18 23:59:20,680 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.id] Set parameter: index=1, jdbcType=VARCHAR, value=simple 2002-06-18 23:59:20,707 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Get result: index=1, javaType=boolean, Simple, value=true 2002-06-18 23:59:20,709 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Get result: index=2, javaType=java.lang.Boolean, Simple, value=false 2002-06-18 23:59:20,713 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Get result: index=3, javaType=byte, Simple, value=11 2002-06-18 23:59:20,715 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Get result: index=4, javaType=java.lang.Byte, Simple, value=22 2002-06-18 23:59:20,717 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Get result: index=5, javaType=short, Simple, value=33 2002-06-18 23:59:20,718 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Get result: index=6, javaType=java.lang.Short, Simple, value=44 2002-06-18 23:59:20,720 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Get result: index=7, javaType=int, Simple, value=55 2002-06-18 23:59:20,726 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Get result: index=8, javaType=java.lang.Integer, Simple, value=66 2002-06-18 23:59:20,728 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Get result: index=9, javaType=long, Simple, value=77 2002-06-18 23:59:20,730 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Get result: index=10, javaType=java.lang.Long, Simple, value=88 2002-06-18 23:59:20,731 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Get result: index=11, javaType=float, Simple, value=11.11 2002-06-18 23:59:20,733 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Get result: index=12, javaType=java.lang.Float, Simple, value=22.22 2002-06-18 23:59:20,735 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive] Get result: index=13, javaType=double, Simple, value=33.33 2002-06-18 23:59:20,738 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject] Get result: index=14, javaType=java.lang.Double, Simple, value=44.44 2002-06-18 23:59:20,740 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue] Get result: index=15, javaType=java.lang.String, Simple, value=test string value 2002-06-18 23:59:20,742 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue] Get result: index=16, javaType=java.util.Date, Simple, value=1970-01-01 11:00:01.111 2002-06-18
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
We've had nothing but headaches using the Oracle JDBC drivers. They don't handle LOBs the way everyone else does, especially when the size is greater than 4000. That's a specific cuttoff. Anything below that will behave the way you'd expect. Anything over that will certainly fail unless you code specifically to handle it (at least in our testing). Here are a couple articles that may be useful: http://otn.oracle.com/doc/java.815/a64685/oraext4.htm#1043351 http://technet.oracle.com/sample_code/tech/java/sqlj_jdbc/files/jdbc20/LOBSa mple/LOBSample.java.html Hope this is helpful. Brian - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 11:04 AM Subject: Re: [JBoss-dev] Oracle BLOB handling - FIXED? This is the way the code was before I integrated the Oracle BLOB patch. The problem is the serialized stream is being truncated to 4000 bytes. I just got an email from someone willing to work on implementing correct BLOB handling. I'd still like someone to try this in Oracle 8. -dain Stephen Coy wrote: I've done some more poking at this, and modified JDBCUtil.setParameter as follows: // // Binary types need to be converted to a byte array and set // if(isBinaryJDBCType(jdbcType)) { byte[] bytes = convertObjectToByteArray(value); if (bytes.length 2000 jdbcType != Types.BLOB) { // it's more efficient to use setBinaryStream for large // streams, and causes problems if not done on some DBMS // implementations ps.setBytes(index, bytes); } else { InputStream in = null; try { in = new ByteArrayInputStream(bytes); ps.setBinaryStream(index, in, bytes.length); } finally { safeClose(in); } } return; ie. Forget about the ByteArrayBlob class. This works fine when writing to the database. However, reading the data back fails: 2002-06-18 23:59:20,671 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.SimpleEJB] Executing SQL: SELECT booleanPrimitive, booleanObject, bytePrimitive, byteObject, shortPrimitive, shortObject, integerPrimitive, integerObject, longPrimitive, longObject, floatPrimitive, floatObject, doublePrimitive, doubleObject, stringValue, utilDateValue, sqlDateValue, timeValue, timestampValue, bigDecimalValue, byteArrayValue, objectValue FROM SIMPLE WHERE (id=?) 2002-06-18 23:59:20,680 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.id] Set parameter: index=1, jdbcType=VARCHAR, value=simple 2002-06-18 23:59:20,707 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.boolea nPrimitive] Get result: index=1, javaType=boolean, Simple, value=true 2002-06-18 23:59:20,709 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.boolea nObject] Get result: index=2, javaType=java.lang.Boolean, Simple, value=false 2002-06-18 23:59:20,713 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePr imitive] Get result: index=3, javaType=byte, Simple, value=11 2002-06-18 23:59:20,715 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteOb ject] Get result: index=4, javaType=java.lang.Byte, Simple, value=22 2002-06-18 23:59:20,717 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortP rimitive] Get result: index=5, javaType=short, Simple, value=33 2002-06-18 23:59:20,718 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortO bject] Get result: index=6, javaType=java.lang.Short, Simple, value=44 2002-06-18 23:59:20,720 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.intege rPrimitive] Get result: index=7, javaType=int, Simple, value=55 2002-06-18 23:59:20,726 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.intege rObject] Get result: index=8, javaType=java.lang.Integer, Simple, value=66 2002-06-18 23:59:20,728 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPr imitive] Get result: index=9, javaType=long, Simple, value=77 2002-06-18 23:59:20,730 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longOb ject] Get result: index=10, javaType=java.lang.Long, Simple, value=88 2002-06-18 23:59:20,731 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatP rimitive] Get result: index=11, javaType=float, Simple, value=11.11 2002-06-18 23:59:20,733 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatO bject] Get result: index=12,
[JBoss-dev] CMP in JBoss!
Hi : Is there a way to store the state of an EB in more than one relational table using CMP in JBoss. Our entity model requires such a persistence model , is this possible in JBoss-CMP. Thanks in advance. Regards, muthu __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP in JBoss!
No. This is planed for a future release. You can use one-to-one relationships. -dain Muthumuaran A wrote: Hi : Is there a way to store the state of an EB in more than one relational table using CMP in JBoss. Our entity model requires such a persistence model , is this possible in JBoss-CMP. Thanks in advance. Regards, muthu __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JDK 1.4 use in JBoss
How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Oracle BLOB handling - FIXED?
One of the problems we discovered with Oracle LOB types while using them in a 2-tier environment was that the LOB lengths were being recorded incorrectly. (even when using the Oracle specific LOB classes) As long as the LOB grew in length, there was no problem. As soon as you wrote back a LOB that was shorter than the prior instance, errors occurred. The way we got around this was to create a PL/SQL block like this: begin DBMS_LOB.TRIM(?, ?);DBMS_LOB.TRIM(?, ?); end; That would be executed within the same DB transaction that housed the update. Karl Koster [EMAIL PROTECTED] Sempra Energy Trading -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Oracle BLOB handling - FIXED? This is the way the code was before I integrated the Oracle BLOB patch. The problem is the serialized stream is being truncated to 4000 bytes. I just got an email from someone willing to work on implementing correct BLOB handling. I'd still like someone to try this in Oracle 8. -dain Stephen Coy wrote: I've done some more poking at this, and modified JDBCUtil.setParameter as follows: // // Binary types need to be converted to a byte array and set // if(isBinaryJDBCType(jdbcType)) { byte[] bytes = convertObjectToByteArray(value); if (bytes.length 2000 jdbcType != Types.BLOB) { // it's more efficient to use setBinaryStream for large // streams, and causes problems if not done on some DBMS // implementations ps.setBytes(index, bytes); } else { InputStream in = null; try { in = new ByteArrayInputStream(bytes); ps.setBinaryStream(index, in, bytes.length); } finally { safeClose(in); } } return; ie. Forget about the ByteArrayBlob class. This works fine when writing to the database. However, reading the data back fails: 2002-06-18 23:59:20,671 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.SimpleEJB] Executing SQL: SELECT booleanPrimitive, booleanObject, bytePrimitive, byteObject, shortPrimitive, shortObject, integerPrimitive, integerObject, longPrimitive, longObject, floatPrimitive, floatObject, doublePrimitive, doubleObject, stringValue, utilDateValue, sqlDateValue, timeValue, timestampValue, bigDecimalValue, byteArrayValue, objectValue FROM SIMPLE WHERE (id=?) 2002-06-18 23:59:20,680 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.id] Set parameter: index=1, jdbcType=VARCHAR, value=simple 2002-06-18 23:59:20,707 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Get result: index=1, javaType=boolean, Simple, value=true 2002-06-18 23:59:20,709 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Get result: index=2, javaType=java.lang.Boolean, Simple, value=false 2002-06-18 23:59:20,713 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Get result: index=3, javaType=byte, Simple, value=11 2002-06-18 23:59:20,715 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Get result: index=4, javaType=java.lang.Byte, Simple, value=22 2002-06-18 23:59:20,717 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Get result: index=5, javaType=short, Simple, value=33 2002-06-18 23:59:20,718 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Get result: index=6, javaType=java.lang.Short, Simple, value=44 2002-06-18 23:59:20,720 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Get result: index=7, javaType=int, Simple, value=55 2002-06-18 23:59:20,726 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Get result: index=8, javaType=java.lang.Integer, Simple, value=66 2002-06-18 23:59:20,728 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Get result: index=9, javaType=long, Simple, value=77 2002-06-18 23:59:20,730 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Get result: index=10, javaType=java.lang.Long, Simple, value=88 2002-06-18 23:59:20,731 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Get result: index=11, javaType=float, Simple, value=11.11 2002-06-18 23:59:20,733 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Get result: index=12, javaType=java.lang.Float, Simple, value=22.22 2002-06-18
[JBoss-dev] [ jboss-Bugs-554535 ] Oracle BLOB and byte array
Bugs item #554535, was opened at 2002-05-10 15:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=554535group_id=22866 Category: JBossCMP Group: v2.4 (stable) Status: Open Resolution: Accepted Priority: 5 Submitted By: Niall O'Sullivan (nosullivan) Assigned to: Dain Sundstrom (dsundstrom) Summary: Oracle BLOB and byte array Initial Comment: Re-submiting a bug that was never fixed and closed. The Orginial problem was [ 434620 ] Oracle BLOB and byte array The Conclusion was If this problem persists with JBoss 2.4 or 3 then please report it again. JBoss 2.2 is not supported anymore. I can confirm that this is still a bug in 2.4. JBoss: JBoss-2.4.4_Jetty-3.1.7-1 OS: Windows 2K and Windows NT JDK: 1.4 DB: Oracle 8.1.6 The suggested fix in [434620] works for me but hasn't been integrated into jboss and presumably hasn't been tested against other DBs. -- Comment By: Niall O'Sullivan (nosullivan) Date: 2002-06-18 16:40 Message: Logged In: YES user_id=540986 Is this working? I've got following exception with oracle driver (8.1.7): Your problem appears to be un-related. This bug was to do with reading blobs, and it only effected org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand, you seem to have problems writing blobs. -- Comment By: Cezary Zawadka (czawadka) Date: 2002-06-18 10:26 Message: Logged In: YES user_id=311672 Is this working? I've got following exception with oracle driver (8.1.7): java.lang.ClassCastException: org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob at oracle.jdbc.driver.OraclePreparedStatement.setBlob (OraclePreparedStatement.java:1446) at org.jboss.resource.adapter.jdbc.local.LocalPreparedStatement.set Blob(LocalPreparedStatement.java:680) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter (JDBCUtil.java:220) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid ge.setArgumentParameters (JDBCAbstractCMPFieldBridge.java:283) In oracle driver (OraclePreparedStatement) is: public synchronized void setBlob(int i, Blob blob) throws SQLException { setBLOB(i, (BLOB)blob); } The same code is in the current release (9.2.0.1) of oracle driver. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-16 20:20 Message: Logged In: YES user_id=251431 This patch has been integrated into JBossCMP (HEAD) with some slight modifications (see original patch for details). I NEED YOU TO TEST THIS (IN HEAD) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=554535group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I can't believe france is out of the world cup
man what a cup! Italy out... simone, yeah you can cry on my shoulder I know the feeling, Only Spain is exciting these days, But I really want Senegal to win :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Ignacio Coloma |Sent: Thursday, June 06, 2002 12:15 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] I can't believe france is out of the world cup | | |Maybe. Just promise not to get pissed off when the spanish fury sieges |the fields. | |You have been warned :-))) | |Vesco Claudio wrote: | |Go Italy!!! | |uhmmm, can we change jboss-development in soccer-jboss? :-))) | | Claudio | |-Original Message- |From:Sacha Labourey [SMTP:[EMAIL PROTECTED]] |Sent:Thursday, June 06, 2002 4:30 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] I can't believe france is out of the world |cup | |Come on, Tomasson will kick them out with 3-0 ! | |Ah, justice is made ! Go Italy ! | |Simone, I personnaly don't care much about football: I just give a little |support for French. Today football, this week-end the legislative |elections, |pfhh... what a hard time! ;) | |But I am sure you know what I mean: Italian situation has strong |similarities with France, but a few year earlier! ;) | |This new World-Cup mailing-list is cool! | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] I can't believe france is out of the world cup
As long as the USA don't win but they shall defeat Germany and send them home. Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 11:06 AM Subject: RE: [JBoss-dev] I can't believe france is out of the world cup man what a cup! Italy out... simone, yeah you can cry on my shoulder I know the feeling, Only Spain is exciting these days, But I really want Senegal to win :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Ignacio Coloma |Sent: Thursday, June 06, 2002 12:15 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] I can't believe france is out of the world cup | | |Maybe. Just promise not to get pissed off when the spanish fury sieges |the fields. | |You have been warned :-))) | |Vesco Claudio wrote: | |Go Italy!!! | |uhmmm, can we change jboss-development in soccer-jboss? :-))) | | Claudio | |-Original Message- |From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] |Sent: Thursday, June 06, 2002 4:30 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] I can't believe france is out of the world |cup | |Come on, Tomasson will kick them out with 3-0 ! | |Ah, justice is made ! Go Italy ! | |Simone, I personnaly don't care much about football: I just give a little |support for French. Today football, this week-end the legislative |elections, |pfhh... what a hard time! ;) | |But I am sure you know what I mean: Italian situation has strong |similarities with France, but a few year earlier! ;) | |This new World-Cup mailing-list is cool! | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Difficulty upgrading from 2.4.3 to 3.0.0 -- datasources
the configuration of datasources is a scary mess, will iron that out soon marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Howard M. Lewis Ship |Sent: Thursday, June 13, 2002 8:41 AM |To: JBoss Dev |Cc: Tapestry Developer |Subject: [JBoss-dev] Difficulty upgrading from 2.4.3 to 3.0.0 -- |datasources | | |I'm in the middle of upgrading from JBoss 2.4.3 to JBoss 3.0.0. I |like much |of what I see, but I'm having trouble clearing one key hurdle. | |My database is driven by McKoiDB 0.92; I created a simple MBean to start |McKoi as a thread inside JBoss, and created a datasource for it: | |[2.4.3 jboss.jcml] | | mbean code=net.sf.tapestry.contrib.mckoi.McKoiDB |name=DefaultDomain:service=McKoiDB | attribute name=RootPath../db/attribute | attribute name=ConfigPath../db/vlib.conf/attribute | /mbean | | mbean code=org.jboss.jdbc.JdbcProvider |name=DefaultDomain:service=JdbcProvider,name=McKoiDB |attribute name=Driverscom.mckoi.JDBCDriver/attribute | /mbean | | mbean code=org.jboss.jdbc.XADataSourceLoader |name=DefaultDomain:service=XADataSource,name=XAVlib |attribute name=PoolNameMcKoiDB/attribute |attribute |name=DataSourceClassorg.jboss.pool.jdbc.xa.wrapper.XADataSourceI |mpl/attr |ibute |attribute name=Properties/ |attribute name=URLjdbc:mckoi://localhost//attribute |attribute name=GCMinIdleTime120/attribute |attribute name=JDBCUseradmin/attribute |attribute name=MaxSize10/attribute |attribute name=Passwordsecret/attribute |attribute name=GCEnabledfalse/attribute |attribute name=InvalidateOnErrorfalse/attribute |attribute name=TimestampUsedfalse/attribute |attribute name=Blockingtrue/attribute |attribute name=GCInterval12/attribute |attribute name=IdleTimeout180/attribute |attribute name=IdleTimeoutEnabledfalse/attribute |attribute name=LoggingEnabledfalse/attribute |attribute name=MaxIdleTimeoutPercent1.0/attribute |attribute name=MinSize0/attribute | /mbean | | |Now, everything's changed in 3.0.0; I've been blindly attempting |to hack the |sample HSQL service into a McKoi service: | |server |!-- | -- |!-- New ConnectionManager setup for default hsql dbs -- |!-- Build jmx-api (build/build.sh all) and view for config |documentation -- |!-- | -- |mbean code=org.jboss.resource.connectionmanager.LocalTxConnectionManager |name=jboss.jca:service=LocalTxCM,name=McKoiDBDataSource |depends |mbean code=net.sf.tapestry.contrib.mckoi.McKoiDB |name=jboss:service=McKoiDB |attribute name=RootPath../server/tapestry/db/attribute |attribute name=ConfigPath../server/tapestry/db/vlib.conf/attribute |/mbean |/depends |depends optional-attribute-name=ManagedConnectionFactoryName |!--embedded mbean-- |mbean code=org.jboss.resource.connectionmanager.RARDeployment |name=jboss.jca:service=LocalTxDS,name=McKoiDBDataSource |attribute name=JndiNameMcKoiDB/attribute |attribute name=ManagedConnectionFactoryProperties |properties |config-property name=ConnectionURL |type=java.lang.Stringjdbc:mckoi://localhost//config-property |config-property name=DriverClass |type=java.lang.Stringcom.mckoi.JDBCDriver/config-property |config-property name=UserName |type=java.lang.Stringadmin/config-property |config-property name=Password |type=java.lang.Stringsecret/config-property |/properties |/attribute |!--Below here are advanced properties -- |!--hack-- |depends |optional-attribute-name=OldRarDeploymentjboss.jca:service=RARDep |loyment,n |ame=JBoss LocalTransaction JDBC Wrapper/depends |dependsjboss:service=McKoiDB/depends |/mbean |/depends |depends optional-attribute-name=ManagedConnectionPool |!--embedded mbean-- |mbean |code=org.jboss.resource.connectionmanager.JBossManagedConnectionPool |name=jboss.jca:service=LocalTxPool,name=McKoiDB |attribute name=MinSize0/attribute |attribute name=MaxSize50/attribute |attribute name=BlockingTimeoutMillis5000/attribute |attribute name=IdleTimeoutMinutes15/attribute |!--criteria indicates if Subject (from security domain) or app supplied |parameters (such as from getConnection(user, pw)) are used to distinguish |connections in the pool. Choices are |ByContainerAndApplication (use both), |ByContainer (use Subject), |ByApplication (use app supplied params only), |ByNothing (all connections are equivalent, usually if adapter supports |reauthentication)-- |attribute name=CriteriaByContainer/attribute |/mbean |/depends |depends |optional-attribute-name=CachedConnectionManagerjboss.jca:service |=CachedCo |nnectionManager/depends |depends |optional-attribute-name=JaasSecurityManagerServicejboss.security |:name=Jaa |sSecurityManager/depends |attribute name=TransactionManagerjava:/TransactionManager/attribute |!--make the rar deploy! hack till better deployment-- |dependsjboss.jca:service=RARDeployer/depends |/mbean |/server | | | |When I
RE: [JBoss-dev] Has the CCE problem been fixed?
I thought Scott said this was fixed what is the story? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Tuesday, June 18, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Has the CCE problem been fixed? run jrockit marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, June 17, 2002 12:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Has the CCE problem been fixed? If so has the fixed been integrated into Branch_3_0, if so when? --jason
RE: [JBoss-dev] JMX Meta data
|It won't do multiple languages yet AFAIK, but how about using the xmbean |functionality? You can put the descriptions in your source files and |generate the xmbean xml descriptors using xdoclet. I don't know if jetty That's really cool, does it support initial values for the attributes as well? marcf |is using the jboss service controller stuff to load its mbeans, but that |system will now deploy xmbeans. | |I think we are planning to move all our mbeans to xmbeans when we have a |little time;-) | |Or are you trying to do something else? | |david jencks | |On 2002.06.10 07:54:51 -0400 Greg Wilkins wrote: | Juha, | | I'd like to extend the JMX metadata generation to search for proper | descriptions for MBeans, attributes, methods and parameters from resource | files. | | If you startup a JBoss that uses Jetty, you will see via the JMX agent | that all the jetty MBeans have descriptive text associated with them. | This text is obtained from mbean_en.properties files which are searched | for on the package/inheritance hierarchy of the MBean. | | I think it adds significantly to the usability of the JMX interface. | | It should be a pretty simple addition to the StandardMetaData | class. As you appear to be the main author of the JMX stuff, I thought | I'd clear it with you before adding this capability. | | Of course, even with this capability, we would still need other | developers | to actually write the mbean.properties files - but at least there would | be | a standard mechanism to document the MBeans. | | regards | | | | -- | Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 | Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 | http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Has the CCE problem been fixed?
It has. Marc is still playing catch-up with his email. -dain Jason Dillon wrote: I thought Scott said this was fixed? what is the story? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Tuesday, June 18, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Has the CCE problem been fixed? run jrockit marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, June 17, 2002 12:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Has the CCE problem been fixed? If so has the fixed been integrated into Branch_3_0, if so when? --jason -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] I can't believe france is out of the world cup
If it weren't for Prendergast we(Belgians) would have beaten Brasil ! /Werner (who knows nothing about football, but has the Belgian Football Association running on JBoss :-))) Andreas Schaefer wrote: As long as the USA don't win but they shall defeat Germany and send them home. Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 11:06 AM Subject: RE: [JBoss-dev] I can't believe france is out of the world cup man what a cup! Italy out... simone, yeah you can cry on my shoulder I know the feeling, Only Spain is exciting these days, But I really want Senegal to win :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Ignacio Coloma |Sent: Thursday, June 06, 2002 12:15 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] I can't believe france is out of the world cup | | |Maybe. Just promise not to get pissed off when the spanish fury sieges |the fields. | |You have been warned :-))) | |Vesco Claudio wrote: | |Go Italy!!! | |uhmmm, can we change jboss-development in soccer-jboss? :-))) | | Claudio | |-Original Message- |From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] |Sent: Thursday, June 06, 2002 4:30 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] I can't believe france is out of the world |cup | |Come on, Tomasson will kick them out with 3-0 ! | |Ah, justice is made ! Go Italy ! | |Simone, I personnaly don't care much about football: I just give a little |support for French. Today football, this week-end the legislative |elections, |pfhh... what a hard time! ;) | |But I am sure you know what I mean: Italian situation has strong |similarities with France, but a few year earlier! ;) | |This new World-Cup mailing-list is cool! | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- ir. Werner Ramaekers Enterprise Java Solutions Architect - Shift@ Sun Certified Java Programmer May the source be with you. mailto:[EMAIL PROTECTED] http://www.shiftat.com -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
Since we are doing preprocessing of the source, are we going to have two releases, one for 1.3 and one for 1.4? -dain Vesco Claudio wrote: I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
There is not preprocessing for the connector module, substitute classes are used. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Since we are doing preprocessing of the source, are we going to have two releases, one for 1.3 and one for 1.4? -dain Vesco Claudio wrote: I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject:[JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] I can't believe france is out of the world cup
hi, On Tue, 2002-06-18 at 20:19, Andreas Schaefer wrote: As long as the USA don't win but they shall defeat Germany and send them home. lol. as it looks germany will march through and take the cup by defeating the three mighty football giants usa, south korea and turkey. what i'm really hoping for though is a final between germany and england. with germany winning 1:0 by an offside goal in minute 93 of regular playtime. cheers, christian Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
You probably need to implement a version based plugin, like the jrmp proxy stuff used to have. Hopefully then we could build the release with 1.4 and have it still work on 1.3. Or will that lead to strange shit? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 9:13 AM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-569305 ] Server IP detection causes problems
Bugs item #569305, was opened at 2002-06-15 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Terrell (j3110) Assigned to: Nobody/Anonymous (nobody) Summary: Server IP detection causes problems Initial Comment: By default, on some Linux distributions, for performance and other reasons (some interfaces have dynamic IP's but the hosts ip shouldn't change), the host name of the local machine is configured to point to 127.0.0.1. When connecting through JNDI from a remote machine, the IP set in jndi.properties is overwritten with 127.0.0.1 on the client side. Obviously, this causes the client to fail connecting to the server. Other servers, Apache for example, warn the user that this is probably undesired behavior and allow a way to manually override the local IP with an option in the configuration files. -- Comment By: Joao Pedro Clemente (jpcl) Date: 2002-06-18 20:35 Message: Logged In: YES user_id=169196 For what I've read from other J2EE platform manuals, I guess this happens 'cause of misuse of IP address. I'm not sure if I understood the failure cenario completely, but it seems that this would not happen if the client would use the server name instead of ip address. This is similar to some failures that happen when using a http proxy server that badly resolve dns names, if I'm not mistaken. Is it really necessary that the server sends the IP address to the client? Are you sure this is not a problem of your machines network configuration? Maybe you could give more details on your setup/machine configuration? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 18-June-2002
Number of tests run: 617 Successful tests: 615 Errors:0 Failures: 2 [time of test: 18 June 2002 12:30 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.1.5] See http://lubega.com/testarchive/${build.uid} for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Has the CCE problem been fixed?
There is a patch for 1 of the cases of CCE. There is also a bug in Sun's JVM that we can not hack around. JRockit does not have this problem. On Tue, 2002-06-18 at 14:49, Dain Sundstrom wrote: It has. Marc is still playing catch-up with his email. -dain Jason Dillon wrote: I thought Scott said this was fixed? what is the story? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Tuesday, June 18, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Has the CCE problem been fixed? run jrockit marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, June 17, 2002 12:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Has the CCE problem been fixed? If so has the fixed been integrated into Branch_3_0, if so when? --jason -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
There is preprocessing for the local tx wrapper. If its compiled in 1.3 it should work in 1.4 but other problems apparently occur the other way. david jencks On 2002.06.18 15:16:21 -0400 Jason Dillon wrote: There is not preprocessing for the connector module, substitute classes are used. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Since we are doing preprocessing of the source, are we going to have two releases, one for 1.3 and one for 1.4? -dain Vesco Claudio wrote: I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I can't believe france is out of the world cup
| As long as the USA don't win but they shall defeat Germany | and send them home. | |lol. as it looks germany will march through and take the cup by |defeating the three mighty football giants usa, south korea and turkey. don't be so fucking cocky look what it got france g |what i'm really hoping for though is a final between germany and |england. with germany winning 1:0 by an offside goal in minute 93 of |regular playtime. yeah something tells me ... senegal... I'll be cheering for them marcf Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX Meta data
On 2002.06.18 14:44:36 -0400 marc fleury wrote: |It won't do multiple languages yet AFAIK, but how about using the xmbean |functionality? You can put the descriptions in your source files and |generate the xmbean xml descriptors using xdoclet. I don't know if jetty That's really cool, does it support initial values for the attributes as well? Not yet AFAIK, it would require a special attribute interceptor. Right now its metadata only, no actual data. There's another subtask to generate skeleton *-service.xml files. This would be pretty trivial to modify to include default values. I think of the xmbean descriptor as part of the mbean definition ATM, and the values in *-service.xml as part of the configuration. I guess if we put initial values in the xmbean descriptor then the service.xml only needs a list of what mbeans to deploy. It would mean that xmbean descriptors were unique to an mbean instance rather than a class. This starts to look a little like something Juha was talking about, separating which mbeans are in the server from their configuration. david jencks marcf |is using the jboss service controller stuff to load its mbeans, but that |system will now deploy xmbeans. | |I think we are planning to move all our mbeans to xmbeans when we have a |little time;-) | |Or are you trying to do something else? | |david jencks | |On 2002.06.10 07:54:51 -0400 Greg Wilkins wrote: | Juha, | | I'd like to extend the JMX metadata generation to search for proper | descriptions for MBeans, attributes, methods and parameters from resource | files. | | If you startup a JBoss that uses Jetty, you will see via the JMX agent | that all the jetty MBeans have descriptive text associated with them. | This text is obtained from mbean_en.properties files which are searched | for on the package/inheritance hierarchy of the MBean. | | I think it adds significantly to the usability of the JMX interface. | | It should be a pretty simple addition to the StandardMetaData | class. As you appear to be the main author of the JMX stuff, I thought | I'd clear it with you before adding this capability. | | Of course, even with this capability, we would still need other | developers | to actually write the mbean.properties files - but at least there would | be | a standard mechanism to document the MBeans. | | regards | | | | -- | Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 | Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 | http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
Pre-processed by what? The java folks really fucked up when they removed pre-processor support say it was only useful arch specific issues, which java doesn't have (which we all know is shit)... but they screwed themselves since we really need a robust pre-processor to handle the jvm version issues... sucks, those pompous bastards. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss There is preprocessing for the local tx wrapper. If its compiled in 1.3 it should work in 1.4 but other problems apparently occur the other way. david jencks On 2002.06.18 15:16:21 -0400 Jason Dillon wrote: There is not preprocessing for the connector module, substitute classes are used. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Since we are doing preprocessing of the source, are we going to have two releases, one for 1.3 and one for 1.4? -dain Vesco Claudio wrote: I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject:[JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
Yeah, what I do in this case is define an interface and supply per-JVM implementations of the interface. I instantiate them (from class name) starting with the JDK 1.4 version and, if that fails, back to the 1.3, 1.2, etc. version. The trick is to compile each class with the correct compiler. Lot's of Ant tricks there. -- [EMAIL PROTECTED] http://tapestry.sf.net Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-570786 ] FileURLConnection getContentType
Bugs item #570786, was opened at 2002-06-18 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570786group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jason Levine (jfl123) Assigned to: Nobody/Anonymous (nobody) Summary: FileURLConnection getContentType Initial Comment: JBoss's FileURLConnection always returns null for the content type. This is a problem for packages like IBM's wsdl4j which can accept the url of a file. I have made a change to the class which probably is not completely correct but at least allowed me to get a valid content type. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570786group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
by ant copy, filter=true. david On 2002.06.18 16:31:02 -0400 Jason Dillon wrote: Pre-processed by what? The java folks really fucked up when they removed pre-processor support say it was only useful arch specific issues, which java doesn't have (which we all know is shit)... but they screwed themselves since we really need a robust pre-processor to handle the jvm version issues... sucks, those pompous bastards. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss There is preprocessing for the local tx wrapper. If its compiled in 1.3 it should work in 1.4 but other problems apparently occur the other way. david jencks On 2002.06.18 15:16:21 -0400 Jason Dillon wrote: There is not preprocessing for the connector module, substitute classes are used. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Since we are doing preprocessing of the source, are we going to have two releases, one for 1.3 and one for 1.4? -dain Vesco Claudio wrote: I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] single location to specify resource references?
Hello, I have the following question. I want to set up all of the resource references in one place, such as standardjboss.xml, rather than having to create a jboss.xml file for each bean. If only one bean is specified in standardjboss.xml, then this approach works fine; however, if more than one bean is defined, then this does not work. So, my question is: Is it possible to set up multiple resource references in standardjboss.xml, which will save the developer the trouble of having to add jboss.xml to several pre-created beans? Here's some background info which may be helpful... I have set up a MySQL database server and properly configured JBoss-2.4.4 to set up a datasource. I have also created an entity bean that successfully connects to JBoss application server and inserts a row into the database. The ejb-jar.xml file is as follows: ejb-jar enterprise-beans session ... resource-ref res-ref-namejdbc/TobyDB/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /session /enterprise-beans ... /ejb-jar The standardjboss.xml file is as follows: enterprise-beans entity ejb-nameConverter/ejb-name resource-ref res-ref-namejdbc/InfoDB/res-ref-name jndi-namejava:/jdbc/InfoDS/jndi-name /resource-ref /entity session ejb-nameOtherBean/ejb-name resource-ref res-ref-namejdbc/DataDB/res-ref-name jndi-namejava:/jdbc/DataDS/jndi-name /resource-ref /session /enterprise-beans Thank you, Toby Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-570811 ] Jboss3.0 + Struts1.0.2 ?????How?????
Patches item #570811, was opened at 2002-06-18 19:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=570811group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Diego CElery (dcelery) Assigned to: Nobody/Anonymous (nobody) Summary: Jboss3.0 + Struts1.0.2 ?How? Initial Comment: I have Jboss2.4.4 + Struts1.0.2 and that's all right. But not in Jboss 3.0. error: I have Struts.jat in my WEB-INF/lib in my .war . All my project is in an .ear . Then, i have this error: ClassDefNotFound: ActionForm.. How do i have to do it work fine? I am from 3 weeks ago with this problem!! Help me please Diego [EMAIL PROTECTED] -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=570811group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
On Tue, 18 Jun 2002, David Jencks wrote: I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks During init, check what the current vm is. If 1.3, replace self with Foo13. If 1.4, replace self with Foo14. Reflection would only get used at init time, and not runtime. Of course, I'm not certain how hard it is to do that 'replace self' bit. Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy
Re: [JBoss-dev] JDK 1.4 use in JBoss
1.3 has to be supported as long as 1.4 doesn't work with jboss (problems include Classcastex. in port.rem.obj.narrow and nullpointer on ear with war inside on jetty)! On Tue, Jun 18, 2002 at 11:12:30AM -0500, Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- MVH Marius Kotsbak Boost communications AS Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf
[JBoss-dev] [ jboss-Bugs-570851 ] Odd Hot Deploy Behavior
Bugs item #570851, was opened at 2002-06-18 23:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570851group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) Assigned to: Nobody/Anonymous (nobody) Summary: Odd Hot Deploy Behavior Initial Comment: As documented here: http://geocrawler.com/mail/msg.php3? msg_id=8965788list=10767 I have observed some odd hot deploy behavior that can be replicated by deploying the two attached files to a default JBoss 3.0.0 server. The xml file declares a reference to an MBean that is implemented in the jar file. Once you are running, touching the xml file will cause the MBean to stop, and then restart. Touching the jar file causes the MBean to stop, but it never restarts. This is mildly annoying because during a typical development cycle the jar file is what changes, and the xml file remains fairly constant. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570851group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 19-June-2002
Number of tests run: 793 Successful tests: 784 Errors:5 Failures: 4 [time of test: 19 June 2002 0:47 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20010626 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20010626/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
I think we might have to create our own interface which exposes the 1.4 stuff, so we can still compile on 1.3... even if those methods will be no-ops. Then you can use a proxy created from a factory that invokes onto a version specific impl (throwing exceptions for the methods which are not exposed for that version). Or you can use a bridge object which handles creating the target version specific impl and then proxy all relavent calls to the impl. I think the proxy is easier, since it reduces each call to an invoke()... then it simply has to invoke on the target, and if the target throws MNFE, we throw some vm version mismatch error or something. I would have a look, but I am still trying to get SwiftMQ to work with the JMS RA. Seems like SwiftMQ does not accept TMJOIN, only TMRESUME and TMNOFLAGS. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
Man did I open a can or worms. I am going to put the JDBC 3.0 code into plug able classes. The question I have is how are we building the JDK 1.4 classes. If we compile on 1.4 will it run on 1.3? -dain Jason Dillon wrote: I think we might have to create our own interface which exposes the 1.4 stuff, so we can still compile on 1.3... even if those methods will be no-ops. Then you can use a proxy created from a factory that invokes onto a version specific impl (throwing exceptions for the methods which are not exposed for that version). Or you can use a bridge object which handles creating the target version specific impl and then proxy all relavent calls to the impl. I think the proxy is easier, since it reduces each call to an invoke()... then it simply has to invoke on the target, and if the target throws MNFE, we throw some vm version mismatch error or something. I would have a look, but I am still trying to get SwiftMQ to work with the JMS RA. Seems like SwiftMQ does not accept TMJOIN, only TMRESUME and TMNOFLAGS. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy
Re: [JBoss-dev] JDK 1.4 use in JBoss
We need to support it until J2ME upgrades to 1.4, and considering they are not quite at 1.3 yet, it will be a couple of years. -dain [EMAIL PROTECTED] wrote: 1.3 has to be supported as long as 1.4 doesn't work with jboss (problems include Classcastex. in port.rem.obj.narrow and nullpointer on ear with war inside on jetty)! On Tue, Jun 18, 2002 at 11:12:30AM -0500, Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC - Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
If you create an interface which extends from the java.whatever interface, then define the methods that differ between the supported version (so add the new methods from 1.4), then our code can use that interface on 1.4 or 1.3 and it will compile. You should then use org.jboss.util.platform.Java to conditional execute code based on versions: if (Java.isCompatible(Java.VERSION_1_3)) { // stuff for 1.3 } if (Java.isCompatible(Java.VERSION_1_4)) { // stuff for 1.4 } or use Java.getVersion() then switch(version) { case Java.VERSION_1_3: blah } --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Tuesday, June 18, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JDK 1.4 use in JBoss I think we might have to create our own interface which exposes the 1.4 stuff, so we can still compile on 1.3... even if those methods will be no-ops. Then you can use a proxy created from a factory that invokes onto a version specific impl (throwing exceptions for the methods which are not exposed for that version). Or you can use a bridge object which handles creating the target version specific impl and then proxy all relavent calls to the impl. I think the proxy is easier, since it reduces each call to an invoke()... then it simply has to invoke on the target, and if the target throws MNFE, we throw some vm version mismatch error or something. I would have a look, but I am still trying to get SwiftMQ to work with the JMS RA. Seems like SwiftMQ does not accept TMJOIN, only TMRESUME and TMNOFLAGS. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa
[JBoss-dev] URL Resource ?
Hi Geeks Maybe this is a stupid question but does JBoss has a URL resource to provide clients with URLs ? Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4 use in JBoss
On 2002.06.18 19:59:01 -0400 Jason Dillon wrote: I think we might have to create our own interface which exposes the 1.4 stuff, so we can still compile on 1.3... even if those methods will be no-ops. Then you can use a proxy created from a factory that invokes onto a version specific impl (throwing exceptions for the methods which are not exposed for that version). Or you can use a bridge object which handles creating the target version specific impl and then proxy all relavent calls to the impl. I think the proxy is easier, since it reduces each call to an invoke()... then it simply has to invoke on the target, and if the target throws MNFE, we throw some vm version mismatch error or something. I would have a look, but I am still trying to get SwiftMQ to work with the JMS RA. Seems like SwiftMQ does not accept TMJOIN, only TMRESUME and TMNOFLAGS. I don't completely understand which flag should be used when. If you always give it TMRESUME when we had TMJOIN what happens? If this doesn't work, does it make any difference to set the managed connection pool size to 1? david --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain --
RE: [JBoss-dev] JDK 1.4 use in JBoss
I assume that 1.4 will generate byte code which 1.3 vms can read and not freak out. See my response to myself on how to branch based on version + interfacing issues that should be all we need to make this work... but there are probably some details I am overlooking. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, June 18, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Man did I open a can or worms. I am going to put the JDBC 3.0 code into plug able classes. The question I have is how are we building the JDK 1.4 classes. If we compile on 1.4 will it run on 1.3? -dain Jason Dillon wrote: I think we might have to create our own interface which exposes the 1.4 stuff, so we can still compile on 1.3... even if those methods will be no-ops. Then you can use a proxy created from a factory that invokes onto a version specific impl (throwing exceptions for the methods which are not exposed for that version). Or you can use a bridge object which handles creating the target version specific impl and then proxy all relavent calls to the impl. I think the proxy is easier, since it reduces each call to an invoke()... then it simply has to invoke on the target, and if the target throws MNFE, we throw some vm version mismatch error or something. I would have a look, but I am still trying to get SwiftMQ to work with the JMS RA. Seems like SwiftMQ does not accept TMJOIN, only TMRESUME and TMNOFLAGS. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss On 2002.06.18 18:56:26 -0400 Jason Dillon wrote: It is a trade off, either complex build or fancy proxy-bridge system. I think it would be in our interest to figure out a way to do the later, as we will always have to deal with this shit. Better that then releasing a JBoss-Java-1.3 and JBoss-Java-1.4 + all of the JBoss variants. That is ridiculous. OK, agreed;-) Maybe we're talking too hard on this and trying out too little. The relevant code is implementations of jdbc 3 methods not present in jdbc 2, that do some checking and forward the call to the (jdbc 3) wrapped object. This is never going to compile on 1.3 unless we give the compiler the jdbc 3 interfaces to compile against. However, a 1.4 compiled version with appropriate class file format ought to work fine on 1.3 (am I right here?). If you call an unavailable method, that's your problem. david jencks --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss Doing something fancy for this is ridiculous-- its in a jca adapter that wraps a jdbc driver. We should just compile one for each jdk version and by default use the one for jdk 1.3. Is it easy to compile both in one run? david jencks On 2002.06.18 17:54:53 -0400 Jason Dillon wrote: The only way I can think of to do this would be to use proxies, where the IH has a reference to the version specific impl. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss I don't see how to compile something on 1.3 that calls a method that is not in the jdbc 2 spec, but if you have a reference to an example of how to do what you suggest I'll take a look. IMO reflection is worse than a preprocessor. david jencks On 2002.06.18 16:34:24 -0400 Jason Dillon wrote: Can this be implemented using a bridge pattern to allow the version specific code to vary from VM to VM as specified by the Java version the VM supports? This would be better IMO than use a preprocessor. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Tuesday, June 18, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JDK 1.4 use in JBoss compile on jdk 1.4, the local wrapper gets the 1.4 jdbc 3 compile on jdk 1.3, you get jdbc 2 done with ant filtering to put/not put comments around jdbc 3 code. I think the xa stuff doesn't wrap the stuff with jdbc 2 to 3 changes. david jencks On 2002.06.18 12:12:30 -0400 Dain Sundstrom wrote: How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still
Re: [JBoss-dev] URL Resource ?
Yes, there are examples of this in the naming ENC unit tests. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Andreas Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 5:34 PM Subject: [JBoss-dev] URL Resource ? Hi Geeks Maybe this is a stupid question but does JBoss has a URL resource to provide clients with URLs ? Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 19-June-2002
Number of tests run: 783 Successful tests: 773 Errors:7 Failures: 3 [time of test: 19 June 2002 2:36 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-570212 ] 3.0.1: CMR, EJBException
Bugs item #570212, was opened at 2002-06-17 15:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570212group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Dain Sundstrom (dsundstrom) Summary: 3.0.1: CMR, EJBException Initial Comment: Every time I try to create a bean with an foreign key, I get an EJBException: Number of input values does not match number of question marks. It sees that org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setArgumentParameters is called to often. Look at the extract from server.log attached. All country-beans are created successfully. The first address-bean, which has a reference to countr (country_id) fails with this error. P.S.: With JBoss 3.0.0 all works fine. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-18 21:47 Message: Logged In: YES user_id=251431 Fixed in HEAD and BRANCH-3_0 -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-17 17:57 Message: Logged In: YES user_id=251431 The trace log really helped. This is a bug in the new start up code in JDBCStoreManager. The command objects are constructed before the relationships are resolved, and the JDBCCreateEntityCommand builds the insert query in the constructor. I'll fix this tomorrow morning. -- Comment By: Frank Langelage (lafr) Date: 2002-06-17 17:02 Message: Logged In: YES user_id=300021 I don't think that it is a mapping problem, but I attached the files as reauested. For EJB address there are 8 fields / parameters / question marks. But JBoss tries to set parameter number nine with null. This causes the error / EJBException. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-06-17 16:07 Message: Logged In: YES user_id=251431 I am going to guess you have some weird unsupported mapping. Can your attach the ejb-jar.xml and jbosscmp-jdbc.xml file? Also can you increase the log level to trace and post the parameters set for the failed command? -- Comment By: Frank Langelage (lafr) Date: 2002-06-17 16:01 Message: Logged In: YES user_id=300021 server.log was too big, so now a reduce version. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570212group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 19-June-2002
Number of tests run: 790 Successful tests: 780 Errors:6 Failures: 4 [time of test: 19 June 2002 3:57 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_j2sdk140 for the junit report of this test. - http://lubega.com/testarchive/sun_j2sdk140/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-570943 ] InvokerInterceptor method isLocal()
Bugs item #570943, was opened at 2002-06-18 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570943group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Yanik Crepeau (yanikc) Assigned to: Nobody/Anonymous (nobody) Summary: InvokerInterceptor method isLocal() Initial Comment: The method isLocal() in org.jboss.invocation.InvokerInterceptor is prone to error. It uses System.currentTimeMillis() to check if the timestamp set during the class loading is the same than the timestamp copied from the class when the instance has been created. Since currentTimeMillis() has a milli-second granularity, there are chances that both remote and local version of the class could have the same timestamp. To address this, I have changed the boolean isLocal() method to use java.rmi.dgc.VMID. This class (present in J2SDK 1.2 distribution) has been designed to return a String that is unique over all virtual machines running on a network. The file included contains the proposed patch. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=570943group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-570951 ] InvokerInterceptor method isLocal()
Patches item #570951, was opened at 2002-06-19 00:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=570951group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yanik Crepeau (yanikc) Assigned to: Nobody/Anonymous (nobody) Summary: InvokerInterceptor method isLocal() Initial Comment: The method isLocal() in org.jboss.invocation.InvokerInterceptor is prone to error. It uses System.currentTimeMillis() to check if the timestamp set during the class loading is the same than the timestamp copied from the class when the instance has been created. Since currentTimeMillis() has a milli-second granularity, there are chances that both remote and local version of the class could have the same timestamp. To address this, I have changed the boolean isLocal() method to use java.rmi.dgc.VMID. This class (present in J2SDK 1.2 distribution) has been designed to return a String that is unique over all virtual machines running on a network. The file included contains the proposed patch. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=570951group_id=22866 Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 19-June-2002
Number of tests run: 759 Successful tests: 745 Errors:12 Failures: 2 [time of test: 19 June 2002 5:17 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20020124 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20020124/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 19-June-2002
Number of tests run: 791 Successful tests: 782 Errors:6 Failures: 3 [time of test: 19 June 2002 6:34 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02b-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/blackdown_jdk131_02b_native for the junit report of this test. - http://lubega.com/testarchive/blackdown_jdk131_02b_native/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development