[JBoss-dev] Cleaning up LOB support in JDBCUtil.java
Hi Dain, I've been doing some work on making the binary data support more portable in JDBCUtil.java. In particular, I wanted to get all use cases of this working with Oracle, where (despite what I may have said before) there are still issues with BLOBS. Current Oracle JDBC drivers absolutely do support the use of the java.sql.* apis for accessing LOBS and the other forms of binary data (VARBINARY, etc). I believe that you added the code that uses org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob to try and resolve the Oracle issues. Please correct me if I am wrong as I've ditched it because Oracle barfs on it (technically, the provision of a java.sql.Blob implementation is in the driver's domain). The only other issue was the use of byte[] bytes = rs.getBytes(index); in getResult. According to the javadoc, ResultSet.getBytes() returns raw bytes from the driver. In Oracle's case, this seems to be the LOB pointer or something, rather than the LOB data. However, going direct to ResultSet.getBinaryStream works fine, so I've modified convertByteArrayToObject to take an InputStream instead, which seems to be a bit more streamlined as you were wrapping the array in a ByteArrayInputStream anyway, unless it already happened to be expecting a byte array. Currently, I have my changes working in Branch_3_0, and the cmp2 test suite passes using both Hypersonic and Oracle. I'll get it working in Branch_3_2 as well. I want to emphasize that I have not used any Oracle apis for this work, only the java.sql.* interfaces. This will not fix the Oracle issues with LOB size when using the thin drivers. The only way to fix that problem is to use the oci drivers. Anyway, I wanted to run this past you and make sure that I'm not working at cross purposes with anyone else before checking it in. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JbossTX vs. Tyrex
Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Cleaning up LOB support in JDBCUtil.java
great stuff steve. Keep it up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Coy Sent: Friday, September 27, 2002 4:40 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Cleaning up LOB support in JDBCUtil.java Hi Dain, I've been doing some work on making the binary data support more portable in JDBCUtil.java. In particular, I wanted to get all use cases of this working with Oracle, where (despite what I may have said before) there are still issues with BLOBS. Current Oracle JDBC drivers absolutely do support the use of the java.sql.* apis for accessing LOBS and the other forms of binary data (VARBINARY, etc). I believe that you added the code that uses org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob to try and resolve the Oracle issues. Please correct me if I am wrong as I've ditched it because Oracle barfs on it (technically, the provision of a java.sql.Blob implementation is in the driver's domain). The only other issue was the use of byte[] bytes = rs.getBytes(index); in getResult. According to the javadoc, ResultSet.getBytes() returns raw bytes from the driver. In Oracle's case, this seems to be the LOB pointer or something, rather than the LOB data. However, going direct to ResultSet.getBinaryStream works fine, so I've modified convertByteArrayToObject to take an InputStream instead, which seems to be a bit more streamlined as you were wrapping the array in a ByteArrayInputStream anyway, unless it already happened to be expecting a byte array. Currently, I have my changes working in Branch_3_0, and the cmp2 test suite passes using both Hypersonic and Oracle. I'll get it working in Branch_3_2 as well. I want to emphasize that I have not used any Oracle apis for this work, only the java.sql.* interfaces. This will not fix the Oracle issues with LOB size when using the thin drivers. The only way to fix that problem is to use the oci drivers. Anyway, I wanted to run this past you and make sure that I'm not working at cross purposes with anyone else before checking it in. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The distributed part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
Thank you, David. JBossTX still has problems with oracle (see for example #614116 I've been working on recently) and I was thinking if it worth fixing or we can switch to Tyrex. I have a solution that will solve JBossTX compatibility problems once and forever, however this solution is not trivial to implement and I am looking for alternatives. David Jencks wrote: jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The distributed part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615553 ] Bean Load generates way more SQL
Bugs item #615553, was opened at 2002-09-27 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 Category: JBossCMP Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Bean Load generates way more SQL Initial Comment: I'm using most of the default jboss settings. I wasn't able to change the read-ahead settings (see other bug, which is now fixed). I have a finder method that returns in this case 1106 entity beans. Then i iterate through the collection and grab most of the data. This takes an enormous amount of time. Some 900,000ms in one particular test. I looked at the sql jboss generated in the server.log file and beleive that there is some looping error because it is generating way too much sql. According to my understanding the default readahead settings will cause jboss to construct a sql statement with 255 ORs, hense reading the 1106 rows in 5 different sql statements. But JBoss is actually creating 1106 sql statements with varring amounts of ORs. Some times JBoss executes sql statements with the same large number 255, i think. Other times it does a series of 255, 254, 2531. It's actually a pretty waterfall effect. I could post my log file, but it's like 5mbs. Dain, please email me if you'd like the log file sent directly to you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615553 ] Bean Load generates way more SQL
Bugs item #615553, was opened at 2002-09-27 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 Category: JBossCMP Group: v3.1 Status: Open Resolution: None Priority: 9 Submitted By: Peter Luttrell (objec) Assigned to: Dain Sundstrom (dsundstrom) Summary: Bean Load generates way more SQL Initial Comment: I'm using most of the default jboss settings. I wasn't able to change the read-ahead settings (see other bug, which is now fixed). I have a finder method that returns in this case 1106 entity beans. Then i iterate through the collection and grab most of the data. This takes an enormous amount of time. Some 900,000ms in one particular test. I looked at the sql jboss generated in the server.log file and beleive that there is some looping error because it is generating way too much sql. According to my understanding the default readahead settings will cause jboss to construct a sql statement with 255 ORs, hense reading the 1106 rows in 5 different sql statements. But JBoss is actually creating 1106 sql statements with varring amounts of ORs. Some times JBoss executes sql statements with the same large number 255, i think. Other times it does a series of 255, 254, 2531. It's actually a pretty waterfall effect. I could post my log file, but it's like 5mbs. Dain, please email me if you'd like the log file sent directly to you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
Hi Igor, I'd like to stick with the jboss tm and add the needed functionality. Can you outline what you have been thinking of? Also, is the new xa wrapper in cvs HEAD working well enough to move to 3.2? Should we even move it to 3.0? I think there may still be issues in what xa flags we send in the start/end calls, but I haven't had time to make a complete analysis. Thanks! david jencks On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: Thank you, David. JBossTX still has problems with oracle (see for example #614116 I've been working on recently) and I was thinking if it worth fixing or we can switch to Tyrex. I have a solution that will solve JBossTX compatibility problems once and forever, however this solution is not trivial to implement and I am looking for alternatives. David Jencks wrote: jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The distributed part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615553 ] Bean Load generates way more SQL
Bugs item #615553, was opened at 2002-09-27 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 Category: JBossCMP Group: v3.1 Status: Closed Resolution: Invalid Priority: 9 Submitted By: Peter Luttrell (objec) Assigned to: Dain Sundstrom (dsundstrom) Summary: Bean Load generates way more SQL Initial Comment: I'm using most of the default jboss settings. I wasn't able to change the read-ahead settings (see other bug, which is now fixed). I have a finder method that returns in this case 1106 entity beans. Then i iterate through the collection and grab most of the data. This takes an enormous amount of time. Some 900,000ms in one particular test. I looked at the sql jboss generated in the server.log file and beleive that there is some looping error because it is generating way too much sql. According to my understanding the default readahead settings will cause jboss to construct a sql statement with 255 ORs, hense reading the 1106 rows in 5 different sql statements. But JBoss is actually creating 1106 sql statements with varring amounts of ORs. Some times JBoss executes sql statements with the same large number 255, i think. Other times it does a series of 255, 254, 2531. It's actually a pretty waterfall effect. I could post my log file, but it's like 5mbs. Dain, please email me if you'd like the log file sent directly to you. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-27 11:12 Message: Logged In: YES user_id=251431 Optimized loading is overed in the JBossCMP documentation chapter 6. Look for the O(n^2) section. The problem is you are not using a transaction. BTW, changing the priority does not get your bug fixed any faster. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615553group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Gosling has Web Services right...
What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss - Components Library
Hello, I would like to know the point of view of the JBoss developer team about the thread JBoss - Components Library in the JBoss-User mailing list. Any comment would be appreciated :) Wonder Sonic ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615650 ] Error in transaction handling
Bugs item #615650, was opened at 2002-09-27 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615650group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Lipp (mlipp) Assigned to: Nobody/Anonymous (nobody) Summary: Error in transaction handling Initial Comment: MDB A calls method m of session bean B. Method m has transaction attribute RequiresNew. B.m throws a runtime exception. In response, A.onMessage calls X.y with X being some EntityBean. As the runtime exception happened in the newly opened transaction, only this sub-transaction should be rolled back, the modification made on X should persist. 3.0.2 behaves as described above. 3.2.0beta rolls back all transactions, including the call to X.y. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615650group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss - Components Library
A lot of what has been mentioned in that thread is already in development in the Forumns on JBoss project. I expect several other application projects under JBoss such as a FAQ manager, BLOGger, Store Front (for docs), Bug tracker, ToDo manager, etc. I think that once we get some basic apps done we will have a better idea about what is portable across apps. -dain wonder sonic wrote: Hello, I would like to know the point of view of the JBoss developer team about the thread JBoss - Components Library in the JBoss-User mailing list. Any comment would be appreciated :) Wonder Sonic --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. 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: 27-September-2002
Number of tests run: 946
Successful tests: 940
Errors:2
Failures: 4
[time of test: 27 September 2002 12:57 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
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!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-615669 ] Patch for bugid # 615667
Patches item #615669, was opened at 2002-09-27 15:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=615669group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Bonham (bonhamcm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bugid # 615667
Initial Comment:
$ cvs -z3 diff -u JDBCUtil.java
Index: JDBCUtil.java
=
==
RCS
file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/c
mp/jdbc/JDBCUtil.java,v
retrieving revision 1.9.2.2
diff -u -r1.9.2.2 JDBCUtil.java
--- JDBCUtil.java 6 Aug 2002 04:15:29 -
1.9.2.2
+++ JDBCUtil.java 27 Sep 2002 19:59:57 -
@@ -208,6 +208,20 @@
return;
}
+ if(jdbcType == Types.LONGVARCHAR)
+ {
+ String string = value.toString();
+ InputStream is = null;
+ try {
+is = new ByteArrayInputStream(string.getBytes
());
+ps.setAsciiStream(index, is, string.length());
+ } finally
+ {
+safeClose(is);
+ }
+ return;
+ }
+
//
// Binary types need to be converted to a byte array
and set
//
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=615669group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615667 ] SQLException storing Oracle LONG
Bugs item #615667, was opened at 2002-09-27 15:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615667group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: SQLException storing Oracle LONG Initial Comment: I'm using JBoss 3.0.2 W2K with JDK 1.3.1_04, Oracle 9i and the Thin drivers. I have a EJB 2.0 bean that uses an Oracle LONG field in its table. Reading from it is fine, but when I try to insert a record greater than 4000 characters, I get this error: [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityComma nd.SnippetCache] Executing SQL: UPDATE CACHE SET CONTENT=?, lastmodifytime=?, timetodie=? WHERE id=? 2002-09-27 14:49:47,838 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: 4633 javax.ejb.EJBException: Internal error setting parameters for field htmlAndHeaderContent; CausedByException is: Data size bigger than max size for this type: 34130 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.setArgumentParameters (JDBCAbstractCMPFieldBridge.java:289) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.setInstanceParameters (JDBCAbstractCMPFieldBridge.java:262) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityComman d.execute(JDBCStoreEntityCommand.java:85) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.store Entity(JDBCStoreManager.java:589) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEnti ty(CMPPersistenceManager.java:458) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.storeEntity (CachedConnectionInterceptor.java:388) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:705) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:99) at org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinT ransaction(EntityContainer.java:172) at org.jboss.ejb.EntityContainer.findLocal (EntityContainer.java:604) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke Home(EntityContainer.java:1116) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv okeHome(EntitySynchronizationInterceptor.java:209) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invokeHome (CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo me(EntityInstanceInterceptor.java:88) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo me(EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:52) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:129) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:487) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv okeHome(BaseLocalContainerInvoker.java:230) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke (LocalHomeProxy.java:110) at $Proxy46.findByKey(Unknown Source) at **private** at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterc eptor.invoke(StatelessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceIntercept or.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke (StatelessSessionContainer.java:313) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke (StatelessSessionProxy.java:81) at
Re: [JBoss-dev] JbossTX vs. Tyrex
David Jencks wrote: Hi Igor, I'd like to stick with the jboss tm and add the needed functionality. Can you outline what you have been thinking of? I want to allow resource manager specific variation of XAResource state change sequence. This way we'll decouple different RMs from each other and developers will be able to concentrate on one RM without concerns to break others. I have very brief idea how this can be implemented, but I believe it is doable and not too complicated. Also, is the new xa wrapper in cvs HEAD working well enough to move to 3.2? Should we even move it to 3.0? What do you think about cached javax.jdbc.XAConnection.getConnection() problem I've mentioned few days ago? Can we afford saying Oracle 8i is not supported in XA mode? I think there may still be issues in what xa flags we send in the start/end calls, but I haven't had time to make a complete analysis. Thanks! david jencks On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: Thank you, David. JBossTX still has problems with oracle (see for example #614116 I've been working on recently) and I was thinking if it worth fixing or we can switch to Tyrex. I have a solution that will solve JBossTX compatibility problems once and forever, however this solution is not trivial to implement and I am looking for alternatives. David Jencks wrote: jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The distributed part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is up with the library available targets?
I can't get this to work. I removed all the * patterns from libraries.ent, removed all the conditional targets Dain put in, and when I try to use it in the jmx mini-project I get BUILD FAILED jar:file:/usr/java/jboss/jbossmx-only/jboss-mx/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: /usr/java/jboss/jbossmx-only/jboss-mx/thirdparty/apache/axis/lib not found. just as I did with the *.jar patterns. Any ideas? thanks david jencks On 2002.09.20 16:34:23 -0400 Jason Dillon wrote: The only bits that are not lazy are the glob specs... like *.jar, so simply listing the jars explicitly will resolve this without needing to check for the availability of them. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 20, 2002 1:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? Juha didn't want all of thirdparty downloaded to build the jmx project (outside of jboss). I wrote something with 2 chunks, roughly jmx-only and all. Dain generalized this to only include libraries that actually are available. I don't completely understand why this is needed either, but apparently some part of the classpath definition has to be there when it is parsed. I thought everything was lazily evaluated, but apparently I was wrong. david jencks On 2002.09.20 15:56:40 -0400 Jason Dillon wrote: Please explain this to me... I don't get why this is needed. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev]
ÒÚ»ªÏòÄãÎʺÃ!ÎÒ¹«Ë¾³¤ÆÚ´Óʹú¼ÊóÒ×,ΪÍÚ¾òÊг¡Ç±Á¦¡¢À©´ó¾Óª¹æÄ£,ÒâÔÚ¹óµØ Ñ°ÕÒÁôÒ×´°¿Ú,Ìؽ«´Ë¼Ûͬ±í³Ê¹óµ¥Î»²Î¿¼.ÎÒ˾ÌṩһÁ÷Æ·ÖÊ,Ò»Á÷·þÎñ, ËÍ»õÉÏÃÅ, ÅúÁí¾ù¿É.»¶Ó¸÷½çÅóÓÑÀ´µç´¹Ñ¯¼°Ö§³Ö.¶àл!!! ÒÚ»ªÃ³Ò×¼¯ÍÅ TAIWAN: ̨±±ÊÐÖÒТ·1113#ÒÚ»ªÉÌÒµ´óÏà ÖйúITóÒײ¿ : ÕŽðÐÛ TEL--0135-15049234 Ò».µçÄÔÅä¼þ(RMB.Ôª): A:ÏÔʾÆ÷ SONY CPD-G420:19\µã¾à:0.25mm\ÊÓƵ´ø¿í:230MHz 2000 CPD-E230:17\µã¾à:0.25mm 1000 CPD-G220:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:203MHz 1400 CPD-G520:21\µã¾à:0.24mm\ÊÓƵ´ø¿í:341MHz 3600 ·ÉÀûÆÖ 107P:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:203MHz 700 107E:17\µã¾à:0.27mm\ÊÓƵ´ø¿í:108MHz 500 105S:15\µã¾à:0.28mm\ÊÓƵ´ø¿í:79MHZ 350 201B:21\µã¾à:0.25mm\ÊÓƵ´ø¿í:261MHz 2200 109B:19\µã¾à:0.25mm\ÊÓƵ´ø¿í:234MHz 1200 109P:19\µã¾à:0.24mm\ÊÓƵ´ø¿í:261MHz 1500 109S:19\µã¾à:0.27mm\ÊÓƵ´ø¿í:203MHz 900 201P:21\µã¾à:0.24mm\ÊÓƵ´ø¿í:320MHz 3200 105E:15\µã¾à:0.28mm\ÊÓƵ´ø¿í:65MHz 300 107B3:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:176MHz 620 107G:17\µã¾à:0.24mm\ÊÓƵ´ø¿í:108MHz 550 107T:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:108MHz 560 ÈýÐÇ 551S/15\µã¾à:0.24mm\ÊÓƵ´ø¿í:65MHz 300 753DF:17\µã¾à:0.20mm\ÊÓƵ´ø¿í:110MHz 450 753S/17\µã¾à:0.23mm\ÊÓƵ´ø¿í:110MHz 480 1100P/21\µã¾à:0.22mm\ÊÓƵ´ø¿í:230MHz 2300 755DF/17\µã¾à:0.20mm\ÊÓƵ´ø¿í:135MHz 560 743DF/ 17\µã¾à:0.20mm\ÊÓƵ´ø¿í:110MHz 440 753DFX/17\µã¾à:0.20mm\ÊÓƵ´ø¿í:110MHz 510 755DFX/17\µã¾à:0.20mm\ÊÓƵ´ø¿í:185MHz 520 757DFX/17\µã¾à:0.20mm\ÊÓƵ´ø¿í:250MHz 780 1200NF:22\µã¾à:0.24mm\ÊÓƵ´ø¿í:340MHz 3000 550S/15\µã¾à:0.24mm\ÊÓƵ´ø¿í:80MHz 360 955DF:19\µã¾à:0.20mm\ÊÓƵ´ø¿í:185MHz 1000 750S/17\µã¾à:0.24mm\ÊÓƵ´ø¿í:110MHz 540 EMC DX787:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:150MHz 510 PF797:17\µã¾à:0.25mm\ÊÓƵ´ø¿í:202.5MHz 560 DX997N:19\µã¾à:0.25mm\ÊÓƵ´ø¿í:202.5MHz 900 PX558/15\µã¾à:0.28mm 300 FX772N/17\µã¾à:0.27mm\ÊÓƵ´ø¿í:120MHz 500 DZ777NS:17\µã¾à:0.20mm\ÊÓƵ´ø¿í:110MHz 500 LT541/15\Òº¾§°åµã¾à:0.297mm 600 HG562/15\Òº¾§°åµã¾à:0.297mm 690 BM468/14.1\Òº¾§°åµã¾à:0.279mm\ÁÁ¶È:180cd/m2\¶Ô±È¶È:200:1 500 568 II/15\Òº¾§°åµã¾à:0.279mm\ÁÁ¶È:200cd/m2\¶Ô±È¶È:400:1 730 BM568/15\Òº¾§°åµã¾à:0.3mm\ÁÁ¶È:200cd/m2\¶Ô±È¶È:350:1 1500 ÈýÐÇ 151S/15\Òº¾§°åµã¾à:0.297mm\ÁÁ¶È:250cd/m2\¶Ô±È¶È:330:1 780 171S/17\Òº¾§°åµã¾à:0.264mm\ÁÁ¶È:250cd/m2\¶Ô±È¶È:350:1 1820 151MP/15\Òº¾§°åµã¾à:0.297mm\ÁÁ¶È:250cd/m2\¶Ô±È¶È:330:1 1600 171MP/17\Òº¾§°åµã¾à:0.264mm\ÁÁ¶È:240cd/m2\¶Ô±È¶È:400:1 2500 210T/21.3\Òº¾§°åµã¾à:0.270mm\ÁÁ¶È:230cd/m2\¶Ô±È¶È:400:1 12000 151BM/15\Òº¾§°åµã¾à:0.297mm\ÁÁ¶È:250cd/m2\¶Ô±È¶È:330:1 900 240T/ 24.06\Òº¾§°åµã¾à:0.270mm\ÁÁ¶È:230cd/m2\¶Ô±È¶È:500:1 19000 151B/15\Òº¾§°åµã¾à:0.297mm\ÁÁ¶È:250cd/m2\¶Ô±È¶È:330:1 1000 SONY SMD-M51/15.1\Òº¾§°åµã¾à:0.3mm\ÁÁ¶È:200 cd/m2\¶Ô±È¶È:300:1 980 SMD-M81/18.1\Òº¾§°åµã¾à:0.3mm\ÁÁ¶È:200 cd/m2\¶Ô±È¶È:300:1 3200 SDM-N50/15\Òº¾§°åµã¾à:0.297mm\ÁÁ¶È:200cd/m2\¶Ô±È¶È:300:1 3000 B:CPU P4 1.7G£¨Socket 478/ºÐ£©500 1.6G£¨Socket 478/É¢£© 500 1.6G£¨Socket 478/ºÐ£© 510 1.5G£¨Socket 478/É¢£© 450 1.7G£¨Socket 478/É¢£© 490 1.5G£¨Socket 478/ºÐ£© 480 1.8GA£¨Socket 478/NORTHWOOD/ºÐ£© 550 2.0GA£¨Socket 478/NORTHWOOD/ºÐ£© 600 1.8G£¨Socket 478/É¢£©590 1.6GA£¨Socket 478/NORTHWOOD/É¢£© 510 1.8GA£¨Socket 478/NORTHWOOD/É¢£© 580 2.0GA£¨Socket 478/NORTHWOOD/É¢£© 620 1.6G£¨Socket 423/É¢£© 500 1.8G£¨Socket 478/ºÐ£© 620 1.6GA£¨Socket 478/NORTHWOOD/ºÐ£© 540 2.0G£¨Socket 478/ºÐ£©700 1.5G£¨Socket 423/ºÐ£© 430 1.5G£¨Socket 423/É¢£© 460 1.7G£¨Socket 423/É¢£©535 2.2GA£¨Socket 478/NORTHWOOD/ºÐ£© 1000 1.7G£¨Socket 423/ºÐ£©480 1.6G£¨Socket 478/NORTHWOOD/ºÐ£©550 2.2GA£¨Socket 478/NORTHWOOD/É¢£©900 1.6G£¨Socket 423/ºÐ£©660 1.9G£¨Socket 478/ºÐ£©700 Celeron 1.0G£¨É¢£©230 P III 1.0G£¨É¢£©420 Celeron 866£¨É¢£©390 Celeron 1.0G£¨256K/É¢£©220 Celeron 1.7G£¨Willamette/É¢£©330 P III 733£¨É¢£©310 Celeron 900£¨É¢£©170 P III 866£¨ºÐ£©400 PIII 933EB£¨É¢£©400 P III 800EB£¨É¢£©380 Celeron 1.2G£¨É¢£©250 P III 850E£¨É¢£©400 Celeron 1.2G£¨TUALATIN/É¢£©230 Celeron 1.3G£¨TUALATIN/É¢£©250 Celeron 1.1G£¨É¢£©220 P III 1.0G£¨ºÐ£©450 Celeron 1.1G£¨TUALATIN/É¢£©200 Celeron 733£¨É¢£©120 P III XEON 700£¨·þÎñÆ÷רÓÃ/1MB£©7000 PIII XEON 700£¨·þÎñÆ÷רÓÃ/2MB£©1 Celeron 850£¨É¢£©160 Celeron 533£¨Socket 370/É¢£©100 Celeron 800£¨É¢£©150 Celeron 566£¨É¢£©120 Celeron 633£¨É¢£©130 Celeron 950£¨É¢£©168 Celeron 766£¨É¢£©150 P III 800EB£¨ºÐ£©3700 P III 700E£¨É¢£©330 P III 933EB£¨ºÐ£©450 P III 1.0G£¨·þÎñÆ÷רÓã©2200 P III 667£¨É¢£©310 XEON 700£¨COMPAQ·þÎñÆ÷רÓÃ/1MB£©7800 XEON 933£¨COMPAQ·þÎñÆ÷רÓã©3800 XEON 1.0GB£¨COMPAQ·þÎñÆ÷רÓã©6500 600£¨COMPAQ·þÎñÆ÷רÓã©2000 667£¨COMPAQ·þÎñÆ÷רÓã© 2000 866£¨COMPAQ·þÎñÆ÷רÓã© 2400 800£¨COMPAQ·þÎñÆ÷רÓã© 4500 Celeron 600£¨É¢£© 135 667£¨É¢£©135 1.7G£¨Willamette/ºÐ£©340 Celeron 1.2G£¨ºÐ£©240 Celeron 700£¨É¢£©150 AMD AthlonXP 1600+£¨É¢£©270 AthlonXP 1700+£¨É¢£©310 AthlonXP 1800+£¨É¢£©370 AthlonXP 1500+£¨É¢£©250 Duron 850£¨É¢£©100 Duron 900£¨É¢£©110 Duron 1.0G£¨É¢£©140 AthlonXP 1900+£¨É¢£©480 Athlon ThunderBird 1.33G£¨266ÍâƵ/É¢£©200 Duron 950£¨É¢£©130 AthlonXP 2000+£¨É¢£©560 Athlon ThunderBird 900£¨É¢£©120 Athlon ThunderBird
[JBoss-dev] creating persistent MBeans dynamically
Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss - Components Library
I have also started putting together application support components in jboss/blocks. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Friday, September 27, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss - Components Library A lot of what has been mentioned in that thread is already in development in the Forumns on JBoss project. I expect several other application projects under JBoss such as a FAQ manager, BLOGger, Store Front (for docs), Bug tracker, ToDo manager, etc. I think that once we get some basic apps done we will have a better idea about what is portable across apps. -dain wonder sonic wrote: Hello, I would like to know the point of view of the JBoss developer team about the thread JBoss - Components Library in the JBoss-User mailing list. Any comment would be appreciated :) Wonder Sonic --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What is up with the library available targets?
What does the property and path definition looks like? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 27, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? I can't get this to work. I removed all the * patterns from libraries.ent, removed all the conditional targets Dain put in, and when I try to use it in the jmx mini-project I get BUILD FAILED jar:file:/usr/java/jboss/jbossmx-only/jboss-mx/tools/lib/buildmagic- tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: /usr/java/jboss/jbossmx-only/jboss-mx/thirdparty/apache/axis/lib not found. just as I did with the *.jar patterns. Any ideas? thanks david jencks On 2002.09.20 16:34:23 -0400 Jason Dillon wrote: The only bits that are not lazy are the glob specs... like *.jar, so simply listing the jars explicitly will resolve this without needing to check for the availability of them. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 20, 2002 1:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? Juha didn't want all of thirdparty downloaded to build the jmx project (outside of jboss). I wrote something with 2 chunks, roughly jmx-only and all. Dain generalized this to only include libraries that actually are available. I don't completely understand why this is needed either, but apparently some part of the classpath definition has to be there when it is parsed. I thought everything was lazily evaluated, but apparently I was wrong. david jencks On 2002.09.20 15:56:40 -0400 Jason Dillon wrote: Please explain this to me... I don't get why this is needed. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Gosling has Web Services right...
It doesn't even have the concept of object identity, so it is even pre Corba. I figure they have about 5 years to catch up with what Corba has today. Of course, I think Corba will continue to die the slow death. -dain danch wrote: Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. Oh, by the way - Web Services also exposes a lot of the detail of the protocol to the programmer, just to really piss off the people who though writing then compiling IDL was a pain in the ass. Now, of course, you get to choose between compiling or generating the IDL, which is so chock full of fun little XML quirks as to be unreadable by normal humans anyway. Bah! The more that things change, the more they get worse. -danch Bill Burke wrote: What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. 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 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is up with the library available targets?
Well, here's the file. david On 2002.09.27 18:13:55 -0400 Jason Dillon wrote: What does the property and path definition looks like? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 27, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? I can't get this to work. I removed all the * patterns from libraries.ent, removed all the conditional targets Dain put in, and when I try to use it in the jmx mini-project I get BUILD FAILED jar:file:/usr/java/jboss/jbossmx-only/jboss-mx/tools/lib/buildmagic- tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: /usr/java/jboss/jbossmx-only/jboss-mx/thirdparty/apache/axis/lib not found. just as I did with the *.jar patterns. Any ideas? thanks david jencks On 2002.09.20 16:34:23 -0400 Jason Dillon wrote: The only bits that are not lazy are the glob specs... like *.jar, so simply listing the jars explicitly will resolve this without needing to check for the availability of them. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 20, 2002 1:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? Juha didn't want all of thirdparty downloaded to build the jmx project (outside of jboss). I wrote something with 2 chunks, roughly jmx-only and all. Dain generalized this to only include libraries that actually are available. I don't completely understand why this is needed either, but apparently some part of the classpath definition has to be there when it is parsed. I thought everything was lazily evaluated, but apparently I was wrong. david jencks On 2002.09.20 15:56:40 -0400 Jason Dillon wrote: Please explain this to me... I don't get why this is needed. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development libraries.ent Description: Binary data
Re: [JBoss-dev] creating persistent MBeans dynamically
There have been some discussions about this, and my opinion is not universally accepted by any means... At the moment there isn't any provision for persisting any mbean configuration and using it in any way. I hope that we can use the persistence stuff you wrote to make the following scheme work easily. I think jboss and the mbean server should be basically a database of mbeans. When you shut down your database server, the contents are saved. Similarly, when you shut down jboss, the mbeans present should be saved and reappear when the mbean server is restarted. Shutting down jboss should not undeploy anything. You didnt' ask to undeploy anything, you asked to stop the server. Similarly, when you restart jboss, the packages that were deployed when you shut down should be in a deployed state when you restart jboss, without having to find them and redeploy them. For instance, if you deploy a package through the ant jmx task or the jmx-console, there is no need for the url to remain accessible after deployment is complete. When you restart jboss, you shouldn't need to access the url, just load the mbeans represented by the deployment from storage. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. As far as the rest of jboss goes, we have to stop undeploying anything on shutdown, and on restart first recreate all the DeploymentInfo mbeans: then the deployment scanner can tell if a package has been refreshed while jboss was down. Thanks david jencks On 2002.09.27 17:23:13 -0400 Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 28-September-2002
Number of tests run: 961 Successful tests: 934 Errors:21 Failures: 6 [time of test: 28 September 2002 2:9 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) 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/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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Gosling has Web Services right...
Hi, I should probably know better to add to this discussion, but... I am unfamiliar with CORBA, and new to Web Services. Nonetheless, the type of web services (SOAP + UDDI) that we are looking at now seems useful to me. Since I think Web Services is useful, I'm of course interested in anything that may be better. For starters, the phrase Web Services makes little sense - might as well call it Buzzword^2. Web Services don't exist on the Web, and, under a sufficiently general definition, what is not a service? The more that things change, the more they get worse. Things are getting better for me. I used to get data from third parties via http posts html scraping. Now I have an API, standards, specifications -- a tool set that doesn't dissapear when I try to interact with someone else's (unique yet similar) interface. Some of the things I've seen written against the Google and Amazon services are impressive. I also find XML-RPC to be useful. How many different, unique yet similar ways do we need to encode requests and responses? XML makes sense to me for data description. Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. As I understand it, the transport protocol is interchangeable in most web services implementations. It also seems that many of your objections are being addressed in layers on top of SOAP. The AXIS and JBoss.Net APIs, for example, hide much of the implementation details. They are there if you need them, of course... As far as the performance issue is concerned, I only ask my systems to be fast enough, and no faster ;) . XML may be verbose, but it can also be compressed. I have seen a few articles about (compressed) binary encoding of XML streams -- I'm interested -- does anyone have any arguments against this? So, if CORBA is a Web Services framework, under the broad definition of Web Services, what makes it better? How should I compare? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, September 27, 2002 8:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Gosling has Web Services right... It doesn't even have the concept of object identity, so it is even pre Corba. I figure they have about 5 years to catch up with what Corba has today. Of course, I think Corba will continue to die the slow death. -dain danch wrote: Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. Oh, by the way - Web Services also exposes a lot of the detail of the protocol to the programmer, just to really piss off the people who though writing then compiling IDL was a pain in the ass. Now, of course, you get to choose between compiling or generating the IDL, which is so chock full of fun little XML quirks as to be unreadable by normal humans anyway. Bah! The more that things change, the more they get worse. -danch Bill Burke wrote: What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. 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 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What is up with the library available targets?
It is possible that the behavior has changed since ant 1.2. You might try using path location=/ instead. Otherwise I don't know. I am working on some ideas for fixing all of this mess right now. The build system has grown and now there are a few more projects going on... so I have bumped up this on my priorities. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 27, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? Well, here's the file. david On 2002.09.27 18:13:55 -0400 Jason Dillon wrote: What does the property and path definition looks like? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 27, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? I can't get this to work. I removed all the * patterns from libraries.ent, removed all the conditional targets Dain put in, and when I try to use it in the jmx mini-project I get BUILD FAILED jar:file:/usr/java/jboss/jbossmx-only/jboss-mx/tools/lib/buildmagic- tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: /usr/java/jboss/jbossmx-only/jboss-mx/thirdparty/apache/axis/lib not found. just as I did with the *.jar patterns. Any ideas? thanks david jencks On 2002.09.20 16:34:23 -0400 Jason Dillon wrote: The only bits that are not lazy are the glob specs... like *.jar, so simply listing the jars explicitly will resolve this without needing to check for the availability of them. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Friday, September 20, 2002 1:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is up with the library available targets? Juha didn't want all of thirdparty downloaded to build the jmx project (outside of jboss). I wrote something with 2 chunks, roughly jmx-only and all. Dain generalized this to only include libraries that actually are available. I don't completely understand why this is needed either, but apparently some part of the classpath definition has to be there when it is parsed. I thought everything was lazily evaluated, but apparently I was wrong. david jencks On 2002.09.20 15:56:40 -0400 Jason Dillon wrote: Please explain this to me... I don't get why this is needed. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Gosling has Web Services right...
Matt wrote: So, if CORBA is a Web Services framework, under the broad definition of Web Services, what makes it better? How should I compare? Take a look at http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=2d3a5b34.0201081 700.548a508c%40posting.google.comrnum=21 Or, if the above is chopped up by your email client, try this http://tinyurl.com/1ofq -- Weiqi Gao [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-615667 ] SQLException storing Oracle LONG
Bugs item #615667, was opened at 2002-09-28 06:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615667group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: SQLException storing Oracle LONG Initial Comment: I'm using JBoss 3.0.2 W2K with JDK 1.3.1_04, Oracle 9i and the Thin drivers. I have a EJB 2.0 bean that uses an Oracle LONG field in its table. Reading from it is fine, but when I try to insert a record greater than 4000 characters, I get this error: [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityComma nd.SnippetCache] Executing SQL: UPDATE CACHE SET CONTENT=?, lastmodifytime=?, timetodie=? WHERE id=? 2002-09-27 14:49:47,838 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: 4633 javax.ejb.EJBException: Internal error setting parameters for field htmlAndHeaderContent; CausedByException is: Data size bigger than max size for this type: 34130 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.setArgumentParameters (JDBCAbstractCMPFieldBridge.java:289) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.setInstanceParameters (JDBCAbstractCMPFieldBridge.java:262) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityComman d.execute(JDBCStoreEntityCommand.java:85) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.store Entity(JDBCStoreManager.java:589) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEnti ty(CMPPersistenceManager.java:458) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.storeEntity (CachedConnectionInterceptor.java:388) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:705) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:99) at org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinT ransaction(EntityContainer.java:172) at org.jboss.ejb.EntityContainer.findLocal (EntityContainer.java:604) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke Home(EntityContainer.java:1116) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv okeHome(EntitySynchronizationInterceptor.java:209) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invokeHome (CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo me(EntityInstanceInterceptor.java:88) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo me(EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:52) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:129) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:487) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv okeHome(BaseLocalContainerInvoker.java:230) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke (LocalHomeProxy.java:110) at $Proxy46.findByKey(Unknown Source) at **private** at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterc eptor.invoke(StatelessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceIntercept or.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke (StatelessSessionContainer.java:313) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke (StatelessSessionProxy.java:81) at
Re: [JBoss-dev] Gosling has Web Services right...
Sorry if I made Corba sound great, because it sucks (that is another story). My beef with web services is that it will be a long time before it is a complete framework. Web services is 80% hype (that is what Gosling is bitching about). -dain Matt Munz wrote: Hi, I should probably know better to add to this discussion, but... I am unfamiliar with CORBA, and new to Web Services. Nonetheless, the type of web services (SOAP + UDDI) that we are looking at now seems useful to me. Since I think Web Services is useful, I'm of course interested in anything that may be better. For starters, the phrase Web Services makes little sense - might as well call it Buzzword^2. Web Services don't exist on the Web, and, under a sufficiently general definition, what is not a service? The more that things change, the more they get worse. Things are getting better for me. I used to get data from third parties via http posts html scraping. Now I have an API, standards, specifications -- a tool set that doesn't dissapear when I try to interact with someone else's (unique yet similar) interface. Some of the things I've seen written against the Google and Amazon services are impressive. I also find XML-RPC to be useful. How many different, unique yet similar ways do we need to encode requests and responses? XML makes sense to me for data description. Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. As I understand it, the transport protocol is interchangeable in most web services implementations. It also seems that many of your objections are being addressed in layers on top of SOAP. The AXIS and JBoss.Net APIs, for example, hide much of the implementation details. They are there if you need them, of course... As far as the performance issue is concerned, I only ask my systems to be fast enough, and no faster ;) . XML may be verbose, but it can also be compressed. I have seen a few articles about (compressed) binary encoding of XML streams -- I'm interested -- does anyone have any arguments against this? So, if CORBA is a Web Services framework, under the broad definition of Web Services, what makes it better? How should I compare? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, September 27, 2002 8:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Gosling has Web Services right... It doesn't even have the concept of object identity, so it is even pre Corba. I figure they have about 5 years to catch up with what Corba has today. Of course, I think Corba will continue to die the slow death. -dain danch wrote: Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. Oh, by the way - Web Services also exposes a lot of the detail of the protocol to the programmer, just to really piss off the people who though writing then compiling IDL was a pain in the ass. Now, of course, you get to choose between compiling or generating the IDL, which is so chock full of fun little XML quirks as to be unreadable by normal humans anyway. Bah! The more that things change, the more they get worse. -danch Bill Burke wrote: What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating persistent MBeans dynamically
make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
David, I've been hearing this in bits an pieces for a while. Thanks for laying it all out. I think that most of that sounds quite sensible, and is in line with my goals for server management. I look at this as a matter of function. Currently, if you want to make a temporary (life of the server) change, you can use the APIs, Adaptors, JMX Console, etc. If you want to make a permanent change, you need to edit the XML and redeploy the MBean. Since one seldom wants to make a temporary change (except when testing, and probably not even then), this makes some of the most interesting functionality less usable. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. I've been putting mine in /conf/mbean-state for now. If object names are unique, then they provide a useful map for persistence locations. I could see user:service=FooMBean being stored at ../mbean-state/user/service/FooMBean.xml (Note the xml extension -- my guess is that the best file based persistence will be XML- and PropertyEditor-based). A similar construct could be used for a JDBC persistence mechanism. The thing that might help with this would be a Persistence Manager MBean that could be used to serialize or load any other MBean (I think you suggested this previously). One question I have is how does all of this relate to the JMX spec. I assume that OnUpdate, Never, etc. values for persistence are part of the spec. There really isn't an OnShutdown. Does the spec mention anything about defaults? It seems to me to be a reasonable behavior to persist unless told not to, but of course I could understand arguments to the contrary as well... Really interesting stuff... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, September 27, 2002 9:08 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] creating persistent MBeans dynamically There have been some discussions about this, and my opinion is not universally accepted by any means... At the moment there isn't any provision for persisting any mbean configuration and using it in any way. I hope that we can use the persistence stuff you wrote to make the following scheme work easily. I think jboss and the mbean server should be basically a database of mbeans. When you shut down your database server, the contents are saved. Similarly, when you shut down jboss, the mbeans present should be saved and reappear when the mbean server is restarted. Shutting down jboss should not undeploy anything. You didnt' ask to undeploy anything, you asked to stop the server. Similarly, when you restart jboss, the packages that were deployed when you shut down should be in a deployed state when you restart jboss, without having to find them and redeploy them. For instance, if you deploy a package through the ant jmx task or the jmx-console, there is no need for the url to remain accessible after deployment is complete. When you restart jboss, you shouldn't need to access the url, just load the mbeans represented by the deployment from storage. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. As far as the rest of jboss goes, we have to stop undeploying anything on shutdown, and on restart first recreate all the DeploymentInfo mbeans: then the deployment scanner can tell if a package has been refreshed while jboss was down. Thanks david jencks On 2002.09.27 17:23:13 -0400 Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree?
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, Ok, that sounds cool. I'll try it on Monday. Have a good weekend. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) at org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoader.java:2 26) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:211) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFi leLoader.java:74) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(J DBCStoreManager.java:677) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(JDBCSto reManager.java:389) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.j ava:339) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager. java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:764) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController .java:976) at $Proxy7.start(Unknown Source) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
More specifically... when my machine can't contact www.jboss.org. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Friday, September 27, 2002 10:41 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss? I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) at org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoader.java:2 26) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:211) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFi leLoader.java:74) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(J DBCStoreManager.java:677) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(JDBCSto reManager.java:389) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.j ava:339) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager. java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:764) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController .java:976) at $Proxy7.start(Unknown Source) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
