Re: [JBoss-dev] optimizing ObjectInputStream.readNonProxyDesc
After hacking a bit, I've managed to put together a version of ObjectInputStream, ObjectStreamClass, etc... that uses a ConcurrentReaderHashMap instead of a synchronized Map within ObjectStreamClass.lookup. Wow!, a simple synchronized of a global map killed performance. The ConcurrentReaderHashMap version was over 60% faster with 200 concurrent threads. My bet is that it would be even better with more concurrent threads. Bill Scott M Stark wrote: Under that kind of contention its certainly possible. Use the thread analyzer to see if the waiting corresponds to the time spent in the suspected hotspot. Scott Stark Chief Technology Officer JBoss Group, LLC Bill Burke wrote: I've been optimizing marshalling by extending ObjectInputStream and OutputStream, and overriding readClassDescriptor and writeClassDescriptor, only marshalling the classname rather than the whole shabang. I even keep a local cache of ObjectStreamClasses for readClassDescriptor to lookup at well (a ConcurrentHashMap). Under load(150 threads), OptimizeIt is still showing readNonProxyDesc as a significant bottleneck (18% in some cases). I'm pretty sure that the problem is in ObjectStreamClass.load(Class, boolean) as there is a global cache for ObjectStreamClass and it is synchronized. Could OptimizeIt be lieing here? Would a simple get of an ObjectStreamClass Map with synchronized access really be such a culprit? To remove this, I have to totally pull and make copies of all affected files to change the cache to a ConcurrentReaderHashMap as non of this stuff is extendible as everything is either package protected or private. --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX DR3 rollback commit
s/test/results/linux/Branch_4_0_DR3/h tml/ --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] optimizing ObjectInputStream.readNonProxyDesc
I've been optimizing marshalling by extending ObjectInputStream and OutputStream, and overriding readClassDescriptor and writeClassDescriptor, only marshalling the classname rather than the whole shabang. I even keep a local cache of ObjectStreamClasses for readClassDescriptor to lookup at well (a ConcurrentHashMap). Under load(150 threads), OptimizeIt is still showing readNonProxyDesc as a significant bottleneck (18% in some cases). I'm pretty sure that the problem is in ObjectStreamClass.load(Class, boolean) as there is a global cache for ObjectStreamClass and it is synchronized. Could OptimizeIt be lieing here? Would a simple get of an ObjectStreamClass Map with synchronized access really be such a culprit? To remove this, I have to totally pull and make copies of all affected files to change the cache to a ConcurrentReaderHashMap as non of this stuff is extendible as everything is either package protected or private. -- ==== Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] optimizing marshalling
Adrian Brock wrote: On Thu, 2003-10-16 at 22:55, Bill Burke wrote: I can optimize marshaling of EJB invocations over wire if I create new classes that extend older versions correct? As long as the old versions still work. A better approach would be to write a new proxy factory, leaving the option to use old proxy factory if older clients need to be supported. They could even be used together using two invoker proxy bindings. Yeah, that's a better idea. Bill --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] optimizing marshalling
I can optimize marshaling of EJB invocations over wire if I create new classes that extend older versions correct? An older EJB RMI client should just download those class versions of the new interceptors, InvocationContexts, and Invocation classes I write. Of course, the PooledInvoker won't work with older versions, but any RMI invocations should be ok with new class types. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] bind address on SNMP agent
Anybody know how to set the Bindaddress on the SNMP agent? Doesn't seem to have this feature. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2.2 Issues to resolve
There are some things I need to get in this release. Can we wait until Friday please. Scott M Stark wrote: All but 786668 have been addressed and the 3.2 branch is being tagged with JBoss_3_2_2. I will complete the final testing tonight and do the release barring any major issues. -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] partitioning jboss for SPECjAppSever2002 ?
I also am looking into Specj. Let's confer offline with performance tunings we both did. Work off of Branch_3_2. We have done huge performance increases since 3.2.2RC3. Optimized a lot of code, fixed a few bugs, and removed almost all global synchronization bottlenecks. (there still may be a few in classloading). Currently I'm working on a "deep" prefetch so that when an entity is loaded, any related bean on the 1: side of a relationship is loaded via a SQL OUTER LEFT JOIN. More comments follow. Christofer Dutz wrote: Hi, sorry for contacting the dev-mailinglist, but my problem couldn't be solved in the user-list. I hoped mabe the developers could help me. As I am still working on SPECjAppServer2002 as a unversity project. The benchmark is runing nicely but I am trying to get even more performance out of jboss. The application consists of 5 parts : Corporate, Manufacturiung, Supplychainmanagement, Customer and Utility. I could monitor quite a lot of inter-cluster-traffic when runing the benchmark and wanted to use the Jboss partitioning to minimize this load. I configured the EJBs in the parts to use different partitions CorpPartition, MfgPartition, SupplyParttion, CustPartitiion and UtilPartition. My netx step was to create 4 jboss configurations. Each configuration should contain UtilPartition and one of the 4 remaining partitions. I did have some Problems configuring this, but I think I managed to do this, by ading a new partition-element in cluster-service.xml and to change the other Services to depend on UtilPartition and the other one. I also added a element (now having 2 of these elements - I don't know if this is correct). Putting things into separate partitions will have no affect except for stateful session bean replication. I think only the CartSes is a stateful bean? HTTP session replication is not required as the Emulator is not supposed to be part of the SUT. If you're putting each DOMAIN (mfg, corp, etc..) into its own JBoss instance this will not work as we do not support distributed transactions. If I deploy the benchmark now I only get some Errors from the EJBs of Partitions that don't run on this server (I woud realy like to get rid of these errors). After deploying the application on all servers and starting the benchmark driver I can see some activity on one host and after a few seconds I get NamingExceptions: could not dereference Object - javax.naming.NameNotBoundException It seems that the HAJNDI seems to fail with this config. I ran in a cluster as well. I turned off SFSB replication and just used regular JNDI on one node. I don't think this is a big deal as most of the time spent right now is in waiting for DB locks to free up anyways. Could you please help me with configuring this the right way? It seems that almost no other applicationserver supports this kond of partitioning and I think this could be a major advantige. Bill -- Bill Burke Chief Architect 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] Andy Oliver's mail address
[EMAIL PROTECTED] Ionel GARDAIS wrote: Hi, Does anybody have Andy Oliver's email address ? I have been told he is developping a mail server for JBoss thanks, ionel ___ 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 -- Bill Burke Chief Architect 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] turn JBoss into an LDAP server
No. Not until we are ready to retire 1.4.x which won't be for at least a year after 1.5 is out. It is just too much to maintain both. Bill Ionel GARDAIS wrote: Does the port to the futur 1.5 Java compiler could be useful ? (like generics, enhanced for loop, static import ...) --- Bill Burke <[EMAIL PROTECTED]> a écrit : > There's other more important stuff like J2EE 1.4 things, administration, and management GUI's if you want to work on any of that. Bill ___ 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 -- ==== Bill Burke Chief Architect 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] turn JBoss into an LDAP server
There's other more important stuff like J2EE 1.4 things, administration, and management GUI's if you want to work on any of that. Bill Brian Stansberry wrote: I too have been looking for something to work on to get involved with JBoss and would be more than happy to help out on adding an LDAP server. Best, Brian At 04:48 PM 9/29/2003 +0200, you wrote: There is a project on sourceforge "javaLDAP". Maybe that can be used as a head start. --Marcus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Monday, September 29, 2003 2:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] turn JBoss into an LDAP server That would be an interesting project. If you or anybody else are serious and get some semi-working code (even just a prototype), I'll get you CVS access and a dev-forum for discussion on it. Regards, Bill Rupp, Heiko wrote: That is something that I'd be interested in (as developer), but I can't promise any timeframe at the moment. Heiko -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 3:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] turn JBoss into an LDAP server It would be good to have a embedded java ldap server. -- Scott Stark Chief Technology Officer JBoss Group, LLC Ionel GARDAIS wrote: Hi, Should it be wise/useful to develop an "LDAP layer" so JBoss could be used as an LDAP server ? ionel --- 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 -- Bill Burke Chief Architect 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 Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 --- 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 -- Bill Burke Chief Architect 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] turn JBoss into an LDAP server
Andy Oliver is working on a mail server. Contact him if you want to work on that. Bill Ionel GARDAIS wrote: --- "Rupp, Heiko" <[EMAIL PROTECTED]> a écrit : > That is something that I'd be interested in (as developer), but I can't promise any timeframe at the moment. So do I. I am looking after a thing to develop to get involve in JBoss I thought of an LDAP server but also a mail server (smtp/pop/imap). These two server could use EJB to store datas. I am still wondering if these kind of applications should be developped as a part of JBoss or as a standalone application, able to deploy on any application server See you later, I'm going back to LDAP rfc readings :) Ionel ___ 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 -- Bill Burke Chief Architect 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] turn JBoss into an LDAP server
That would be an interesting project. If you or anybody else are serious and get some semi-working code (even just a prototype), I'll get you CVS access and a dev-forum for discussion on it. Regards, Bill Rupp, Heiko wrote: That is something that I'd be interested in (as developer), but I can't promise any timeframe at the moment. Heiko -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 3:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] turn JBoss into an LDAP server It would be good to have a embedded java ldap server. -- Scott Stark Chief Technology Officer JBoss Group, LLC Ionel GARDAIS wrote: Hi, Should it be wise/useful to develop an "LDAP layer" so JBoss could be used as an LDAP server ? ionel --- 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 -- ==== Bill Burke Chief Architect 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] Re: cvs sucks these days .. ?!?
Ummm, don't do that, build won't work. C.N.Medappa wrote: try checking out jboss-head with revision Branch_3_2 - Original Message - From: "Rupp, Heiko" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.java.jboss.devel Sent: Wednesday, September 24, 2003 4:08 PM Subject: cvs sucks these days .. ?!? Hi, a fresh checkout Jboss-3.2 with Branch_3_2 always terminates with a error code 1 and e.g thirdparty/ is missing. Can anybody give me a hint? Thanks Heiko -- ==== Bill Burke Chief Architect 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
[JBoss-dev] Removing CachedConnectionInterceptor
Adrian, Are we removing the CachedConnectionInterceptor? We have code in place to replace it? Bill --- 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] is jboss-dev broken?
test... -- Bill Burke Chief Architect 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] statement caching
Ok, I implemented prepared statement caching for our JCA connector. I
see the same 30% improvement I spoke about below. The is with Oracle
9.2 mind you. I did the same test with HSQL and it really ahd no affect.
Bill
Bill Burke wrote:
Hey,
Seems statement caching does make a difference, about 30% difference. I
was always under the assumption that it didn't and finally tested it out
for myself under Oracle 9.2. Here's the test:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.HashMap;
/**
* Created by IntelliJ IDEA.
* User: wburke
* Date: Sep 16, 2003
* Time: 9:07:52 PM
* To change this template use Options | File Templates.
*/
public class pscache
{
/*
CREATE TABLE C_customer
(
c_idinteger not null,
c_firstchar(16),
c_lastchar(16),
c_street1char(20),
c_citychar(20),
c_statechar(2),
c_phonechar(16)
);
*/
public static final String insertQuery = "insert into C_customer
values (?, ?, ?, ?, ?, ?, ?)";
public static final String findQuery = "select c_first, c_last,
c_street1, c_city, c_state, c_phone from C_customer where c_id = ?";
public static final String deleteQuery = "delete from C_customer
where c_id = ?";
public static PreparedStatement createInsert(Connection con) throws
Exception
{
return con.prepareStatement("insert into C_customer values (?, ?,
?, ?, ?, ?, ?)");
}
public static PreparedStatement createFindBy(Connection con) throws
Exception
{
return con.prepareStatement("select c_first, c_last, c_street1,
c_city, c_state, c_phone from C_customer where c_id = ?");
}
public static PreparedStatement createDelete(Connection con) throws
Exception
{
return con.prepareStatement("delete from C_customer where c_id = ?");
}
public static void testNonCachedPS(Connection con, int i) throws
Exception
{
PreparedStatement insert = createInsert(con);
PreparedStatement find = createFindBy(con);
PreparedStatement delete = createDelete(con);
int idx = 0;
insert.setInt(++idx, i);
insert.setString(++idx, "Bill");
insert.setString(++idx, "Burke");
insert.setString(++idx, "10 Blanchard Ave");
insert.setString(++idx, "Billerica");
insert.setString(++idx, "MA");
insert.setString(++idx, "666-666-");
insert.executeUpdate();
insert.close();
find.setInt(1, i);
ResultSet rs = find.executeQuery();
rs.next();
String first = rs.getString("c_first");
String last = rs.getString("c_last");
String street = rs.getString("c_street1");
String city = rs.getString("c_city");
String state = rs.getString("c_state");
String phone = rs.getString("c_phone");
rs.close();
find.close();
delete.setInt(1, i);
delete.executeUpdate();
delete.close();
}
public static HashMap psCache = new HashMap();
public static void testCachedPS(Connection con, int i) throws Exception
{
PreparedStatement insert =
(PreparedStatement)psCache.get(insertQuery);
PreparedStatement find = (PreparedStatement)psCache.get(findQuery);
PreparedStatement delete =
(PreparedStatement)psCache.get(deleteQuery);
int idx = 0;
insert.setInt(++idx, i);
insert.setString(++idx, "Bill");
insert.setString(++idx, "Burke");
insert.setString(++idx, "10 Blanchard Ave");
insert.setString(++idx, "Billerica");
insert.setString(++idx, "MA");
insert.setString(++idx, "666-666-");
insert.executeUpdate();
find.setInt(1, i);
ResultSet rs = find.executeQuery();
rs.next();
String first = rs.getString("c_first");
String last = rs.getString("c_last");
String street = rs.getString("c_street1");
String city = rs.getString("c_city");
String state = rs.getString("c_state");
String phone = rs.getString("c_phone");
rs.close();
delete.setInt(1, i);
delete.executeUpdate();
}
public static void main(String[] args) throws Exception
{
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
Connection con =
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:ziondb",
"ecperf", "ecperf");
long start, end;
start = System.currentTimeMillis();
for (int i = 0; i < 3000; ++i)
{
testNonCachedPS(con, i);
}
end = System.currentTimeMillis() - start;
System.out.println("non cached took: " + end);
con.close();
con
[JBoss-dev] Re: [JBoss-user] JBoss welcomes the Hibernate project
Screwed up my own announcement *blush* Forgot to mention that Gavin King, the creator, leader of Hibernate, is now an employee of JBoss Group! You probably assumed that from reading the post though I hope. Regards, Bill Bill Burke wrote: All, I would sincerely like to welcome Gavin and Hibernate to the JBoss Group and JBoss.org umbrella. I can't tell you how incredibly psyched and excited we at JBoss are about this. Over the past year, I can't tell you how many times we've encountered customers that are using Hibernate or are looking to use Hibernate to replace the clunky design that EJB CMP is. Technically this is a perfect marriage for both projects. We at JBoss have been looking at replacing our aging CMP persistence for over a year now in JBoss 4.0. We are excited that we will be able to leverage Hibernate as the backbone of our persistence solutions rather than having to patch our existing, aging solution or rewriting it from scratch. Hibernate will also become part of our POJO/AOP based solution and a key component of our aspect-oriented middleware offering. These two things alone will expand the userbase and developer base of Hibernate. This means more people finding bugs and more people fixing bugs. JBoss developers have also done a lot of distributed caching work that will be applicable to Hibernate. We will also help Gavin create tighter integration of Hibernate with JBoss for those of you who are interested in that. Things like packaged Hibernate components that can be hot-deployed. JMX management of Hibernate components. Those are just a few of the things that we can introduce. JBoss Group is proud to pionner a model we call "Professional Open Source" whereby JBoss.org grows and JBoss Group recruits the top talent from succesful open source efforts. It enables developers to work fulltime, become pro, on their own projects. Recently JBoss Group recruited Remy Maucherat, the lead developer of Tomcat 5, Julien Viet the developer of Nukes, Bela Ban, creator of JavaGroups, more are coming. JBG offers the rare opportunity to turn from hobbyist open source to professional open source. All core JBoss developers are pro themselves(myself included). JBoss Group professional open source sponsors the top developers to work full time on their projects and thus provides a boost to the projects involved by sponsoring their leaders. Finally the availability of professional services is a boost to corporate adoption of succesful open source projects such as Hibernate. We strongly believe this is the way of the future at JBoss. All and all, I hope you all look favorably on this new relationship. I know I do. Thanks all! Bill -- ==== Bill Burke Chief Architect 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
[JBoss-dev] JBoss welcomes the Hibernate project
All, I would sincerely like to welcome Gavin and Hibernate to the JBoss Group and JBoss.org umbrella. I can't tell you how incredibly psyched and excited we at JBoss are about this. Over the past year, I can't tell you how many times we've encountered customers that are using Hibernate or are looking to use Hibernate to replace the clunky design that EJB CMP is. Technically this is a perfect marriage for both projects. We at JBoss have been looking at replacing our aging CMP persistence for over a year now in JBoss 4.0. We are excited that we will be able to leverage Hibernate as the backbone of our persistence solutions rather than having to patch our existing, aging solution or rewriting it from scratch. Hibernate will also become part of our POJO/AOP based solution and a key component of our aspect-oriented middleware offering. These two things alone will expand the userbase and developer base of Hibernate. This means more people finding bugs and more people fixing bugs. JBoss developers have also done a lot of distributed caching work that will be applicable to Hibernate. We will also help Gavin create tighter integration of Hibernate with JBoss for those of you who are interested in that. Things like packaged Hibernate components that can be hot-deployed. JMX management of Hibernate components. Those are just a few of the things that we can introduce. JBoss Group is proud to pionner a model we call "Professional Open Source" whereby JBoss.org grows and JBoss Group recruits the top talent from succesful open source efforts. It enables developers to work fulltime, become pro, on their own projects. Recently JBoss Group recruited Remy Maucherat, the lead developer of Tomcat 5, Julien Viet the developer of Nukes, Bela Ban, creator of JavaGroups, more are coming. JBG offers the rare opportunity to turn from hobbyist open source to professional open source. All core JBoss developers are pro themselves(myself included). JBoss Group professional open source sponsors the top developers to work full time on their projects and thus provides a boost to the projects involved by sponsoring their leaders. Finally the availability of professional services is a boost to corporate adoption of succesful open source projects such as Hibernate. We strongly believe this is the way of the future at JBoss. All and all, I hope you all look favorably on this new relationship. I know I do. Thanks all! Bill -- ==== Bill Burke Chief Architect 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
[JBoss-dev] JBoss welcomes Bela Ban and JavaGroups
All, JBoss Group is pleased to announce that it has hired the project lead for JavaGroups, Bela Ban. If you don't already know, JavaGroups is the backbone for our clustering implementation and this hiring is a real coup for us. Bela's resume is impressive and his experience with fault tolerance is amazing. Having his expertise on payroll full time will greatly improve the JBoss project as a whole. Besides working on JavaGroups full time, Bela is going to lead our caching efforts as well as help out with clustering and serverless, JavaGroups-based, JMS. JavaGroups now comes under the JBoss Group umbrella and Bela will be providing professional services for JavaGroups as needed. Ok, now the marketing spiel :-) JBoss Group is proud to pionner a model we call "Professional Open Source" whereby JBoss.org grows and JBoss Group recruits the top talent from succesful open source efforts. It enables developers to work fulltime, become pro, on their own projects. Recently JBoss Group recruited Remy Maucherat, the lead developer of Tomcat 5, Julien Viet the developer of Nukes, Gavin King, creator of Hibernate, more are coming. JBG offers the rare opportunity to turn from hobbyist open source to professional open source. All core JBoss developers are pro themselves(myself included). JBoss Group professional open source sponsors the top developers to work full time on their projects and thus provides a boost to the projects involved by sponsoring their leaders. Finally the availability of professional services is a boost to corporate adoption of succesful open source projects such as Hibernate. We strongly believe this is the way of the future at JBoss. Best regards, Bill -- ==== Bill Burke Chief Architect 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
[JBoss-dev] WrappedConnection lifetime/ PS cache
WrappedConnection is not put into the pool, correct? So if I want to implement a PreparedStatement cache, I need to store it in BaseWrapperManagedConnection? Thanks, Bill -- Bill Burke Chief Architect 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
[JBoss-dev] connections should be single threaded no?
Connections should be single threaded, shouldn't they? We're doing some cloning/synchronization in a few places to protect against concurreny when the connection shouldn't have to worry about that. Especially in WrappedConnection.close() -- ==== Bill Burke Chief Architect 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
[JBoss-dev] statement caching
reparedStatement find = createFindBy(con);
PreparedStatement delete = createDelete(con);
psCache.put(insertQuery, insert);
psCache.put(findQuery, find);
psCache.put(deleteQuery, delete);
start = System.currentTimeMillis();
for (int i = 0; i < 3000; ++i)
{
testCachedPS(con, i);
}
end = System.currentTimeMillis() - start;
System.out.println("cached took: " + end);
insert.close();
find.close();
delete.close();
con.close();
}
}
--
Bill Burke
Chief Architect
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
[JBoss-dev] [Fwd: [jboss-group] 3.2.2 Release date]
Original Message Subject: [jboss-group] 3.2.2 Release date Date: Sat, 13 Sep 2003 07:27:08 -0700 From: Scott M Stark <[EMAIL PROTECTED]> Reply-To: Private list for internal JBoss Group discussion <[EMAIL PROTECTED]> Organization: JBoss Group To: [EMAIL PROTECTED] I want to get the 3.2.2 finalized and out on 2003-9-29. Let's target the current optmization work and bug fixes to be in for that. I'm going to do an RC4 release early next week. -- Scott Stark Chief Technology Officer JBoss Group, LLC ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group -- ==== Bill Burke Chief Architect 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
[JBoss-dev] revamping Invocation objects
In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- ==== Bill Burke Chief Architect 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] compile error in today's snapshot from Sun's 1.3.1_07
Sorry, my bad Adrian Brock wrote: Fixed, it now uses org.jboss.util.NestedRuntimeException Regards, Adrian On Thu, 2003-09-11 at 16:26, Rod Burgett wrote: I'm trying to compile the 3.2 snapshot with Sun's 1.3.1_07 jdk. It seems that org.jboss.tm.TxUtils.java is trying to use a RuntimeException constructor with Throwable parameter. But that ctor is only available in 1.4. Has support for 1.3.1 been abandoned, or is this a bug? It can be coaxed through the compiler by changing 'new RuntimeException(ignored)' to 'new RuntimeException(ignored.toString())' in 6 places. Is there a better solution involving a JBoss wrapper exception? Rod Burgett webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) "It's all just 0s & 1s - the trick is getting them lined up in the proper order" --- 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 -- Bill Burke Chief Architect 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
[JBoss-dev] connection listerner lookup has contention
Why are connection listeners for ManagedConnections stored in a shared hashmap within BaseConnectionmanager2? BaseConnectionManager2.getConnectionEventListener(ManagedConnection mc) Why can't the connection listener be stored in the Managed Connection? I'd like to remove this contention. OptimizeIt has this at 32.9% in my little test on a dual CPU machine with 10 threads in contention. Thanks, Bill -- ==== Bill Burke Chief Architect 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] Re: [jboss-group] revamping Invocation objects
The 20% was for Local interfaces and it doesn't break compatibility. Sacha Labourey wrote: I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: vendredi, 12. septembre 2003 01:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect 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 ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group -- Bill Burke Chief Architect 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
[JBoss-dev] Re: [jboss-group] revamping Invocation objects
I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect 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
[JBoss-dev] Re: [jboss-group] revamping Invocation objects
Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect 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
[JBoss-dev] Re: [jboss-group] revamping Invocation objects
Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect 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
[JBoss-dev] make sure to merge 3.2 changes to Head
Since we've done the rollback, it should be much easier to merge future changes you make to 3.2 to HEAD as well. Please consider this when making bug fixes to Branch 3.2. Thanks, Bill -- Bill Burke Chief Architect 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] new ejb ql status?
There will be some interesting developments centered around our CMP engine and persistence story soon. Stay tuned Bill Stefan Groschupf wrote: >Aren't they are already in 3.2.x (except for Sum)? I ask since only found an posting from Dain, that it is planed. If they are - good look for me. ;) Stefan --- 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 -- ==== Bill Burke Chief Architect 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] [JBoss.NET] revised schedule, seeking for volunteers*was* RE: [J Boss-dev] 4.0 rollback 1st phase complete
Christoph, Thanks for the direction and email. I just wanted to say that the Jboss.net stuff was rolled back because it was easiest to rollback EVERYTHING rather than just pieces. JBoss.net wasn't a piece we wanted to rollback. All and all, I hope this rollback forces us to do another iteration on the features we all wanted to add to JBoss 4.0. I know I'm rethinking the AOP stuff. Thanks again Christoph, Bill Jung , Dr. Christoph wrote: Ivelin (& others), Wrt the rollback and how this will affect JB.net, Anil, Bill and me came to the conclusion that the 3.2 code [that already builds upon Axis1.1Final] would be a sufficient base for the next 4 weeks [in which I am on "baby holiday" and most likely neither online nor sitting on a computer anyway ;-] Hence I do not want to turn your current attention from where it is needed now. From my experiences, most people currently work on a combination of the 3.2 runtime and the "head" xdoclet module. Thanks to Neal Sanche, there is a compiled version available at http://www.nsdev.org/jboss/stories/xdoclet-module-jboss-net.jar (not to forget his valuable walkthrough at http://www.nsdev.org/jboss/stories/jboss-net.html). Anil who is now the co-lead would then have a look at porting the UDDI server and driving the JAXR interfaces forward; I would care about reimplementing the WS4EE spec [since the "legacy" 4.0 version builds upon too much deployment code that has definitely faded - especially the xsl deployer which was introducing too much runtime/configuration instabilities]. Nevertheless we need to broaden the team to reach the overall vision of making JBoss.net a "nexus of interoperability" in JBoss4 which is a good opportunity for developers to get aquainted to web services technology (in the order of priority): - We could need someone integrating the still separate junit tests of jb.net (we were an optional module in 3.2!) with the overall testsuite. - We could need someone looking at the xdoclet module (there is a JSR on "Web Service Metadata" pending for which I saw a sneak preview by BEA somewhere ... if we could manage to use these doclet tags as the basis of a WS4EE-xdoclet module, that would be of tremendous usefulness IMHO). - Someone should specialize in making JMX-based web services as comfortable as possible. - Someone should specialize in EJB-based web services and drive forward the existing provider code. - We need an interface to the messaging and remoting modules in order to remove code redundancies. - We need a M$.NET specialist in order to address interoperability issues with C#,VB, etc-Clients. Same holds for Macromedia Flash and JAXRPC4ME. - Someone should get deep knowledge in WS-Security with all its signing, encryption, etc bits and improve the existing connection between JB.Net Security handlers and the jboss security architecture in that direction. - We could need someone having a look at the rolled back smtp/saaj support. These are IMHO extremely fascinating topics for tech-heads and will be highly requested by employers in the next years. Please refer to jboss-devel/anil if you have interest. I´ll send a notice (with a baby picture ;-) when I´m back (and unbelievably keen on doing computing again ;-) Best, CGJ -Original Message- From: Ivelin Ivanov [SMTP:[EMAIL PROTECTED] Sent: Donnerstag, 28. August 2003 19:24 To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] 4.0 rollback 1st phase complete Bill, All my recent commits were in Branch_3_2. Do I need to do something to merge them into HEAD or you already did that? How can I help with the web services work? Where to start? ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.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 -- Bill Burke Chief Architect 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-group] RE: [JBoss-dev] 4.0 rollback 1st phase complete
Yes, it was a PAIN! My fingers hurt from typing in my CVS password so many times. marc fleury wrote: Phew, I am glad we are done, that was what about 2000 emails on cvs-commit? Wow marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, August 28, 2003 12:52 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 4.0 rollback 1st phase complete FYI, I forgot to say that the old HEAD code is under the: Branch_4_0_DR3 Bill Bill Burke wrote: Completed rollback of 4.0 to 3.2 on HEAD. I will start merging 4.0 code tomorrow slowly. I will probably need a lot of help here. Especially in the webservices stuff that was added to 4.0 over the past 9 months. For HEAD modules that exist in Branch_3_2, these modules have been rolled back entirely to the 3.2 series. All new modules in HEAD after 3.2 have been retained in head. Now that we've rolled back, let's start being really careful on how we treat HEAD. HEAD is not a playground. Let's not be sloppy coders. Run the testsuite before you commit anything big. If you are experimenting with a rewrite, create your own branch to work on. Let's keep HEAD stable this time around. Thanks and sorry for the inconveniences. Bill -- ==== Bill Burke Chief Architect 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 ___ jboss-group mailing list [EMAIL PROTECTED] https://mail.jboss.org/mailman/listinfo/jboss-group -- ==== Bill Burke Chief Architect 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] 4.0 rollback 1st phase complete
Anil and Dr. Jung probably have web services under control, but you can ask them. I thought you were looking into getting HA into 3.2 JMS? Your changes may have made it into HEAD if they were added before Tuesday? Bill Ivelin Ivanov wrote: Bill, All my recent commits were in Branch_3_2. Do I need to do something to merge them into HEAD or you already did that? How can I help with the web services work? Where to start? -=Ivelin=- - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, August 28, 2003 11:51 AM Subject: Re: [JBoss-dev] 4.0 rollback 1st phase complete FYI, I forgot to say that the old HEAD code is under the: Branch_4_0_DR3 Bill Bill Burke wrote: Completed rollback of 4.0 to 3.2 on HEAD. I will start merging 4.0 code tomorrow slowly. I will probably need a lot of help here. Especially in the webservices stuff that was added to 4.0 over the past 9 months. For HEAD modules that exist in Branch_3_2, these modules have been rolled back entirely to the 3.2 series. All new modules in HEAD after 3.2 have been retained in head. Now that we've rolled back, let's start being really careful on how we treat HEAD. HEAD is not a playground. Let's not be sloppy coders. Run the testsuite before you commit anything big. If you are experimenting with a rewrite, create your own branch to work on. Let's keep HEAD stable this time around. Thanks and sorry for the inconveniences. Bill -- Bill Burke Chief Architect 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 -- Bill Burke Chief Architect 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] 4.0 rollback 1st phase complete
FYI, I forgot to say that the old HEAD code is under the: Branch_4_0_DR3 Bill Bill Burke wrote: Completed rollback of 4.0 to 3.2 on HEAD. I will start merging 4.0 code tomorrow slowly. I will probably need a lot of help here. Especially in the webservices stuff that was added to 4.0 over the past 9 months. For HEAD modules that exist in Branch_3_2, these modules have been rolled back entirely to the 3.2 series. All new modules in HEAD after 3.2 have been retained in head. Now that we've rolled back, let's start being really careful on how we treat HEAD. HEAD is not a playground. Let's not be sloppy coders. Run the testsuite before you commit anything big. If you are experimenting with a rewrite, create your own branch to work on. Let's keep HEAD stable this time around. Thanks and sorry for the inconveniences. Bill -- ==== Bill Burke Chief Architect 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
[JBoss-dev] 4.0 rollback 1st phase complete
Completed rollback of 4.0 to 3.2 on HEAD. I will start merging 4.0 code tomorrow slowly. I will probably need a lot of help here. Especially in the webservices stuff that was added to 4.0 over the past 9 months. For HEAD modules that exist in Branch_3_2, these modules have been rolled back entirely to the 3.2 series. All new modules in HEAD after 3.2 have been retained in head. Now that we've rolled back, let's start being really careful on how we treat HEAD. HEAD is not a playground. Let's not be sloppy coders. Run the testsuite before you commit anything big. If you are experimenting with a rewrite, create your own branch to work on. Let's keep HEAD stable this time around. Thanks and sorry for the inconveniences. Bill -- ==== Bill Burke Chief Architect 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
[JBoss-dev] 4.0 branch and HEAD freeze
All CVS developers, Do to instabilities and poorly written code added to the deployment and EJB layers by certain developers who are no longer with us, we are rolling back 4.0 to the current 3.2 series and slowly merging in new 4.0 technology like AOP, Remoting, etc. And also rewriting the poorly written code that needs to be in 4.0 as well. We are doing this so that future 4.0 development can be done off of a stable base. I have branched the current HEAD on: Branch_4_0_RC3 I do ask that HEAD work be freezed until I can do this rollback. The rollback will probably take a few days. In the meantime, if you absolutely have to do work, use the branch described above. Sorry for the inconvenience. Best regards, Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] locking and deadlock detection changes in 3.2.2
I made some significant changes to locking and deadlock detection in 3.2.2. If anybody has time, can you look over my changes? I get nervous about making major changes to maintenance releases like the 3.2 series, so any extra eyes debugging this would be much helpful. Thanks. The EntityReentranceInterceptor now locks an EntityEnterpriseContext for the duration of the method call rather than just throwing an exception on reentrancy. The lock is actually a member variable of EntityEnterpriseContext and is implemented in server/src/main/org/jboss/ejb/plugins/lock/NonReentrantLock. I made this change so that NotSupported methods on Entity Beans would not throw an exception when concurrent access happens on these methods. An exception will still be thrown if The same transaction or thread tries to invoke on method one than once. Since we're doing locking in yet another place, this additional lock also introduces another scenario in which deadlock can happen. This is even worse because there is no transaction timeout that will interrupt the blocked threads. So, what I've done is abstracted out deadlock detection into its own classes under: common/src/main/org/jboss/util/deadlock DeadlockDetector.java Resource.java All locks now implement the Resource interface. The Resource interface has one method: getResourceHolder. The DeadlockDetector keeps a global graph of waiting resources so that it can be traversed to detect deadlock. The Reentrant locks(NonReentrantLock) for method locking in the EntityReentranceInterceptor returns a Thread object if the lock was required outside a transaction context, or it returns a Transaction if the lock was required within a transaction context. Now that we have this DeadlockDetector, we can expand deadlock detection to other locks that are beyond the scope of Entity beans. -- ==== Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss Licencing.
According to this post to POI-dev, Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java library will actually infect client code with substantial GNU-ness via Section 6 of the LGPL. (The "Lesser" GPL is supposed to protect only the Library, without infecting code using the library) This, as you might imagine, puts a few LGPL Java projects that previously thought they were embeddable without being viral in a bit of a bind. Various weblogs have further coverage." THIS IS THE IMPORTANT PART Update: 07/18 02:44 GMT by CN: The FSF's Executive Director, Brad Kuhn adds "LGPL's S. 6 allows you to make new works that link with the LGPL'ed code, and license them any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' can even be proprietary; it need not be LGPL'ed." Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Brian > Wallis > Sent: Thursday, August 21, 2003 7:55 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss Licencing. > > > On Thu, 21 Aug 2003 08:21 pm, Juha Lindfors wrote: > > Subclasses would fall under LGPL, as far as I can tell, if they're > > distributed publically. > > What about "implements EntityBean" etc. Surely all my beans are > not now LGPL. > Or "extends ServiceMBeanSupport" so my mbeans are now LGPL. > > I hope not. I think that interpretation would severely limit the > use of the > JBoss. > > brian... > > > > --- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss Licencing.
IANAL. Plugins are ok I think. But any modified JBoss source code must be licensed under LGPL and become itself, open source. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Venkatesh V > Sent: Wednesday, August 20, 2003 3:19 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] JBoss Licencing. > > > Hi All, > > Can we add plugin's to JBoss & modify JBoss > source code and use it for commercial purposes. > > How is the Licence for the JBoss. I have read the LGPL > Licence, but i am not getting it clearly Plz send your > comments. > > TIA > > Regards > Venkatesh V > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > > --- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DistributedReplicantManager.isMasterReplica(String) false positives?
I think this service will be very useful for clustered durable queues and
topics. Keep it up.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Sacha
> Labourey
> Sent: Tuesday, August 05, 2003 2:21 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev]
> DistributedReplicantManager.isMasterReplica(String) false positives?
>
>
> Hello Bela,
>
> Yes, but Scott found two interesting things:
> - it seems that even if two nodes share the same view, the name of the
> members of the view may appear different (one has the name, the
> other the IP
> address)
> - there is an unstable condition somewhere that make the
> singleton service
> flip-flap while it shouldn't be necessary (+ race condition but that's at
> another level)
>
> I will most probably play with the additional code you had added at the
> begginig of the year to add another information to the IpAddress, but for
> this will have to change TCP as well (you only changed UDP) so that this
> additional information is always taken in account when generating new
> IpAddress at the TCP JG protocol layer.
>
> Cheers,
>
>
> Sacha
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Bela Ban
> > Sent: lundi, 4. août 2003 23:55
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev]
> > DistributedReplicantManager.isMasterReplica(String) false positives?
> >
> >
> > The entire logic to determine when to become singleton is
> > handled in the
> > view callback. Since this can potentially be length, and also uses
> > remote group calls, I suggest to run this in a separate
> > thread, so you
> > won't run into a deadlock. By default, HA Clustering does *not* use
> > deadlock detection.
> >
> >
> > Scott M Stark wrote:
> >
> > > There is a race condition i the
> > > DistributedReplicantManager.isMasterReplica(String) that
> > shows up when
> > > this method is called from within a notifyKeyListeners as shown by
> > > this stack trace:
> > >
> > > Thread "main"@65 status: RUNNING
> > > - isMasterReplica():437,
> > > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > > - isDRMMasterReplica():234, org.jboss.ha.jmx.HAServiceMBeanSupport
> > > - partitionTopologyChanged():103,
> > > org.jboss.ha.singleton.HASingletonSupport
> > > - replicantsChanged():197, org.jboss.ha.jmx.HAServiceMBeanSupport$1
> > > - notifyKeyListeners():675,
> > > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > > - add():326,
> > > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > > - registerDRMListener():204, org.jboss.ha.jmx.HAServiceMBeanSupport
> > > - startService():144, org.jboss.ha.jmx.HAServiceMBeanSupport
> > >
> > > This is due the the choice to return true when the key in
> > question is
> > > in the
> > > localReplicants table, but not the replicants table:
> > >
> > >public boolean isMasterReplica (String key)
> > >{
> > > if (!localReplicants.containsKey (key))
> > > return false;
> > >
> > > Vector allNodes = this.partition.getCurrentView ();
> > > HashMap repForKey = (HashMap)replicants.get(key);
> > > if (repForKey==null)
> > > return true;
> > >
> > > This seems to be an ambiguous condition as this condition
> > exists for a
> > > node that calls add and when the state has not synched or
> > has failed
> > > to synch. Another problem I'm seeing at least in the context of the
> > > singleton service is that the notion of the master node is
> > unstable.
> > > Here is the output from one of 3 nodes running the
> > singleton service
> > > starting with the addition of the final node shown as view 2.
> > >
> > > 15:35:44,637 INFO [Server] JBoss (MX MicroKernel)
> > [3.2.2RC3 (build:
> > > CVSTag=Branch_3_2 date=200307312219)] Started in 5s:948ms
> > > 15:36:27,719 INFO [DefaultPartition] New cluster view: 2
> > > ([lamia:32947, 172.17.66.54:2821, ironmaiden:51770] delta: 1)
> > > 15:36:27,749 INFO [DefaultPartition:ReplicantManager] Dead
> > members: 0
> > > 15:37:13,555 INFO [DefaultPartition] New cluster view (id:
> > 3, delta:
> > > -1) : [172.17.66.54:2821, ironmaiden:51770]
> > > 15:37:13,575 INFO [DefaultPartition:ReplicantManager] Dead
> > members: 1
> > > 15:38:13,321 INFO [HASingletonMBeanExample] Notified to start as
> > > singleton
> > > 15:38:13,321 INFO [DefaultPartition] New cluster view (id:
> > 4, delta:
> > > 1) : [172.17.66.54:2821, ironmaiden:51770, lamia:32949]
> > > 15:38:13,331 INFO [DefaultPartition:ReplicantManager] Dead
> > members: 0
> > > 15:38:13,361 INFO [HASingletonMBeanExample] Notified to stop as
> > > singleton
> > > 15:39:13,447 INFO [HASingletonMBeanExample] Notified to start as
> > > singleton
> > > 15:39:13,457 INFO [HASingletonMBeanExample] Notified to stop as
> > > singleton
> > >
> > > With view 3 the orginal node and singleton is killed and
> > the node for
> > > which the console output corresponds(172.17.66.5
RE: [JBoss-dev] Re: [JBoss-user] July 2003 news
Yes, I'd like to know as well. We will address this issues if it is so. Regards, Bill Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Brian > Wallis > Sent: Wednesday, August 06, 2003 7:52 PM > To: [EMAIL PROTECTED]; Vladyslav Kosulin > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] Re: [JBoss-user] July 2003 news > > > On Thu, 7 Aug 2003 05:15, Vladyslav Kosulin wrote: > > P.S. Do you know that there are java source files licensed under GPL > > (not LGPL) in the latest JBoss 3.2.1 and 3.2.2 distributions and even in > > the CVS HEAD? Are you surprised? > > This statement worries me. > > Vlad, can you name one or more specific files that are GPL rather > than LGPL? > > If these do exist what is the plan to rectify what to me seems to > be a serious > problem. Something like this could prevent me from using JBoss at > all. This > is serious if true! > > brian wallis... > > > > --- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072 303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] JBoss-IDE 1.2.0 released
Yes, thank you Laurent! We need to get more visibility for your work. I can't wait to eventually try this out. Thanks again, Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Laurent > Etiemble > Sent: Friday, August 08, 2003 7:26 PM > To: Jboss-Development; Jboss-User > Subject: [JBoss-user] JBoss-IDE 1.2.0 released > > > Hi, > > JBoss-IDE 1.2.0 has been released. > > JBoss-IDE provides the following features : > * The debugging and monitoring of JBoss servers and the > controlling of there > life cycles. > * A very comfortable and sophisticated support for XDoclet (completion and > generation). > (NEW) * An easy way to configure the packaging layout of archives > (packed or > exploded) > (NEW) * A simple way to deploy the packaged and/or exploded archive to a > JBoss server > > Guides and tutorial are available : > http://www.jboss.org/index.html?module=html&op=userdisplay&id=deve > lopers/pro > jects/jboss/jbosside > > Bugs, patches, requests and comments are welcome through the Sourceforge > site and the JBoss forum. > > Laurent. > > > > --- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072 303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Recent CVS removals
JBoss Group, as caretaker of the JBoss project, has recently decided to remove CVS access committers for a few of our committers. We do not remove from CVS without good reason nor without just cause. These are the reasons for the removals: 1. These individuals have refused to discuss design issues on our public forums. It is crucial to have a public record of design discussions so that others may particpate in future work. 2. More importantly, we have learned that they have forked JBoss. We also believe they are preparing to submit it, or some derivation, to the new Apache Geronimo project which would violate copyright and LGPL. Our proof? http://sourceforge.net/projects/elba 3. There is just too much conflict of interest of developers working on two different J2EE projects that are being developed under two very different open-source licenses. JBoss Group believes strongly in the LGPL license and will protect all copyrights held by any JBoss contributor. Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Greg Wilkins > Sent: Wednesday, August 06, 2003 8:37 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-user] Re: Recent CVS removals > > > > Firstly a note to the list moderator: This is a request for CVS access, so > I believe that it is on topic and should not be censored. > > Bill Burke wrote: > > JBoss Group, as caretaker of the JBoss project, has recently decided to > > remove CVS access committers for a few of our committers. We > do not remove > > from CVS without good reason nor without just cause. These are > the reasons > > for the removals: > > I'll take these in reverse order: > > > 3. There is just too much conflict of interest of developers > working on two > > different J2EE projects that are being developed under two > very different > > open-source licenses. > > Surely that is for the developers or their actions to determine? Or is > this taking the Bush doctrine of pre-emptive action to it's > logical extreme? > > There are conflicts all the time in open source development - between the > day job and the project - between license types - between duplicate > projects - between competing clients both using your code - between time > developing and time to have a life etc. > The fact remains that you participated in a JBoss fork. This shows a complete lack of commitment to the JBoss project and community. You have lost the trust of the JBoss project admins. > As the author of Jetty, I have helped it be integrated with > JBoss, JOnAS and > avalon among other proprietary projects. I am serving on JSR154 and give > effort to improve all J2EE containers. I have worked with and submitted > bug reports and patches for tomcat. I frequently consult to competative > companies.I believe I have proven that I can deal with such conflicts > in a professional manner. > Participating in a fork of JBoss is not professional. You and other Jetty developers are listed as CVS developers of Elba. > JBoss has many users and JBG has many clients that they have encouraged > to use Jetty/JBoss as a stable and supported platform. JBoss is > currently > the best J2EE platform out there and I only wish to continue supporting > it - and fullfilling the implicit promise made to all JBoss users that > we will make best efforts to support our contributions. > > If you give us back our CVS access - what harm can it be? If we vandalize > the code, or become idle for a long period - then remove our access. > But we only wish to maintain our contributions and support the JBoss > community. The only reasons that I can see for removing us is so you > can make "no jboss developer" marketting claims. > Granting of CVS is a contract of trust between the project admins and yourself. You have broken this trust. You are free to submit patches through Sourceforge, but you have lost your CVS privilege. > > > 2. More importantly, we have learned that they have forked > JBoss. We also > > believe they are preparing to submit it, or some derivation, to the new > > Apache Geronimo project which would violate copyright and LGPL. > Our proof? > > > > http://sourceforge.net/projects/elba > > I'm not exactly up to speed with the full motivation for Elba, > but it is not > for submission to geronimo - nor would the ASF accept it if it > was offered. > We are contacting ASF to determine what has or has not been submitted. JBoss Group will protect any infringement on copyright or LGPL. > The elba CVS is a totally legal fork of the JBoss code, which after recent > public legal threats is good to know that it can be done if needed. I > do know it was motivated by removing a private trademarc from an open > code base. > Trademark, copyright, and LGPL(or similar license) are all an open-source project has to protect itself from becoming closed source and proprietary. JBoss Group firmly believes in the spirit of LGPL and will protect against any violation. > But whatever, it's got nothing to do with JBoss nor my continuing desire > to support the project. > > > > 1. These individuals have refused to discuss design issues on > our public > > forums. It is crucial to have a public record of design > discussions so that > > others may particpate in future work. > > I have always been willing to discuss issues on jboss-dev. I, Jan, David, > Jeremy, Hiram and others have all posted to this forum recently - although > several such posts were censored. > The forums on www.jboss.org have been the designated place for design discussions since their incepti
RE: [JBoss-dev] JBoss.net::WSDL to UDDI Converter added to JBoss
Congrats Anil! All, Anil is the perfect example of self-motivation the JBoss project needs. With little support from Christoph and I, Anil tackled the UDDI integration. Anil, welcome. Best regards, Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jung > , Dr. Christoph > Sent: Thursday, July 24, 2003 2:49 AM > To: '[EMAIL PROTECTED]' > Subject: AW: [JBoss-dev] JBoss.net::WSDL to UDDI Converter added to > JBoss > > > Anil, > > This is great work. It will enable us to finally attach > the deployment process automatically to uddi registration! > > Cool, > CGJ > > > > -Ursprüngliche Nachricht- > > Von: Anil Saldhana [mailto:[EMAIL PROTECTED] > > Gesendet: Donnerstag, 24. Juli 2003 06:17 > > An: [EMAIL PROTECTED] > > Betreff: [JBoss-dev] JBoss.net::WSDL to UDDI Converter added to JBoss > > > > > > Hello All, > >I have just committed a java file > > "WSDL2UDDIConverter" and a testcase > > "StoreUddiUnitTestCase.java". These enable users to provide > > the url location of a WSDL service and it is deployed in the > > integrated local jUDDI registry. It uses the open source > > UDDI4J/WSDL4J Api. > > > > This is my first commit. So if there are any mistakes > > from my side, please forgive me. > > > > Thanks to Bill and Dr.Jung for the support/motivation > > provided. I also thank Scott for RW access and Peter > > Braswell for the cooperative/informative IM chats. > > > > Cheers, > > Anil > > > > __ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com > > > > > > --- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites > > including Data Reports, E-commerce, Portals, and Forums are > > available now. Download today and enter to win an XBOX or > > Visual Studio .NET. > > http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet > _072303_01/01 > ___ > JBoss-Development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ### > > This message has been scanned by F-Secure Anti-Virus for > Microsoft Exchange. > For more information, connect to http://www.F-Secure.com/ > > > --- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072 303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] passivation in finalize
I do call System.gc() but not in a separate thread, and not every second. That just defeats the purpose. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Anatoly Akkerman > Sent: Friday, July 18, 2003 3:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] passivation in finalize > > > Bill Burke wrote: > > I tried phantom references, but they were never enqueued. See attached. > > > > Bill > > > > Run a separate thread that calls System.gc() repeatedly every second. > > -- > - > Anatoly Akkerman > Computer Science Dept. > Courant Institute of Mathematical Sciences, NYU > 715 Broadway, #719 Tel: 212 998-3493 > New York, NY 10003 Fax: 212 995-4123 > - > > > > --- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] passivation in finalize
I tried phantom references, but they were never enqueued. See attached. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Anatoly Akkerman > Sent: Friday, July 18, 2003 2:34 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] passivation in finalize > > > Bill Burke wrote: > > I did. ReferenceQueue only places the Reference objects in queue. The > > object itself has already been garbage collected. > > > > Bill > > > > Quote from the link Julien submitted: > > Phantomly Reachable > > An object is phantomly reachable when the garbage collector finds no > strong, soft, or weak references, but at least one path to the object > with a phantom reference. Phantomly reachable objects are objects that > have been finalized, but not reclaimed. > > When the garbage collector finds only phantom references to an object, > it enqueues the phantom reference. The program polls the reference queue > and upon notification that the phantom reference is enqueued, performs > post-finalization cleanup processing that requires the object to be > unreachable (such as the deallocation of resources outside the Java > heap). At the end of the post-finalization cleanup code, the program > should call the clear() method on the phantom reference object to set > the reference field to null to make the referent eligible for garbage > collection. > > ... > > The processing always happens in the following order, but there is no > guarantee when the processing will occur: > > * Soft references > * Weak references > * Finalization > * Phantom references > * Reclamation > > > > > It seems phantom references should work. I've never tried it myself, > though. > > -- Anatoly > > > > --- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development refqueue.java Description: java/
RE: [JBoss-dev] passivation in finalize
I did. ReferenceQueue only places the Reference objects in queue. The object itself has already been garbage collected. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > julien viet > Sent: Friday, July 18, 2003 1:38 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] passivation in finalize > > > Have a look at the ReferenceQueue object : > > > A java.lang.ref.ReferenceQueue is a simple data structure onto > which the garbage > collector places reference objects when the reference field is > cleared (set to null). > You would use a reference queue to find out when an object > becomes softly, weakly, > or phantomly reachable so your program can take some action based > on that knowledge. > > For example, a program might perform some post-finalization > cleanup processing > that requires an object to be unreachable (such as the > deallocation of resources > outside the Java heap) upon learning that an object has become > phantomly reachable. > > > > http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/ > > > > > > > > > > > > > > > > I'm trying to figure out a fix for a deadlock scenario with the cache, > passivation, and the OveragerTask. > > I was thinking. Why do all this work to see if a ctx can be > passivated? It > is just error prone. > > Couldn't we just let the garbage collector decide when to passivate? > Implement EnterpriseContext.finalize to > > 1. passivate the ctx > 2. put the object in the pool. > > The javadocs for finalize state that it is ok for the finalize > method to do > stuff like "making this object available again to other threads". So why > all the hassle? > > What are the drawbacks of this? I can't see any right now. > > Thanks, > > Bill > > > Bill Burke > Chief Architect > JBoss Group, LLC > > > > > --- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] passivation in finalize
I'm trying to figure out a fix for a deadlock scenario with the cache, passivation, and the OveragerTask. I was thinking. Why do all this work to see if a ctx can be passivated? It is just error prone. Couldn't we just let the garbage collector decide when to passivate? Implement EnterpriseContext.finalize to 1. passivate the ctx 2. put the object in the pool. The javadocs for finalize state that it is ok for the finalize method to do stuff like "making this object available again to other threads". So why all the hassle? What are the drawbacks of this? I can't see any right now. Thanks, Bill XXXX Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nukes/JBoss?
There is a Nukes forum at www.jboss.org > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Charles Goodwin > Sent: Wednesday, July 16, 2003 8:51 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Nukes/JBoss? > > > 1) I'm looking for the Nukes development mailing list, is this the right > place? > > 2) If it is the right place, have you considered having a separate mailing > list for Nukes given the high traffic nature of this list and the fact > that Nukes is distinctly different from JBoss as an application? > > 3) Can you post a link to your lists on jboss.org? It took me ages to > find this list and I only found it through Google. > > - Charlie > > The future of webapps - www.xwt.org > > > --- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [Fwd: Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref]
I saw the last one. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jan > Bartel > Sent: Friday, July 11, 2003 4:31 AM > To: [EMAIL PROTECTED] > Subject: [Fwd: Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref] > > > This is a re-post as I didn't see this echo on the list. > > Jan > > Original Message > > I have made the changes as agreed: > > + both war deployer and ejb deployer to examine "ejb-link" first for >both "ejb-ref" and "ejb-local-ref". > > + war deployer to have a switch "LenientEjbLink" allowing >misconfigured ejb-links to be ignored for backward >compatibility. This is set to "false" by default, meaning >misconfigured ejb-links will cause a deployment error. > > + war deployer and ejb deployer to support a new element >in jboss descriptors called "ejb-local-ref" which contains a >"local-jndi-name" element, similar to the "ejb-ref" element. >This "ejb-local-ref" in the jboss deployment descriptor is only >consulted in the case that the "ejb-local-ref" in the standard >descriptor does not contain an "ejb-link" element (or in the >case of the war deployer, the "LenientEjbLink" flag has been set >and the "ejb-link" contains a name that cannot be resolved). > > May I please have my cvs write access back so I can commit? > > thanks > Jan > > Scott M Stark wrote: > > Ok, then I agree with adding the ejb-local-ref support. > > > > > > -- > > / > * Jan Bartel <[EMAIL PROTECTED]> > * Associate > * Core Developers Network LLC > * http://www.coredevelopers.net > / > > > > --- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new resource for jboss developers and users
Link doesn't work. :) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rod > Burgett > Sent: Friday, July 11, 2003 7:56 AM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-dev] new resource for jboss developers and users > > > I'm happy to announce the opening of jbossdev.webmethods.com. We want to > provide a resource for information on the JBoss testsuite, what kind of > results or errors you might expect on various OS and JVM combinations. It > is primed with a collection of result sets from 7 operating > systems. If the > combination you use isn't represented, you can post your results. > > It's small now but, with your help, we'll grow it. Check it out. > > This website is supported by webMethods, a JBoss partner. > > > > Rod Burgett > Senior Software Engineer > > webMethods, Inc. > 3930 Pender Drive > Fairfax, VA 22030 USA > Ph: 703.460.5819 (tty only) > > "It's all just 0s & 1s - > the trick is getting them lined up in the proper order" > > > > --- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hiram > Chirino > Sent: Wednesday, July 09, 2003 12:38 AM > To: [EMAIL PROTECTED] > Subject: RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite > > > On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: > > In line... > > > Hiram, > > > > As you may know, we are going in a different direction with JMS than the > > original architecture coded by Norbert Lataille. We are doing a rewrite > > I guess I had it good. Norbert made a good start. At least basic > pub/sub worked. That's better than starting from scratch. > > > so patches to the old JBossMQ have a limited lifetime. That means that > > changes made to the old JBossMQ will most likely not be part of HEAD or > > the distribution as we move forward. > > You may be right. or wrong. The current JMS will ship until there is a > better replacement. Do you plan to replace the current implementation > with the peer based implementation you have been working on? > No, the peer based implementation will only be a flavor. As you already know, multicast can't be used for everything. Bill --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hiram > Chirino > Sent: Wednesday, July 09, 2003 12:16 AM > To: [EMAIL PROTECTED] > Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite > > > Scott, > > Why does it matter? Nathan has not expressed interested in growing from > the current JMS implementation. I've been waiting for several months > for the new general purpose implementation to 'appear' and it has not. There has been a skeleton since early Jun. > So it's time for me to start the engine again and make some needed > improvements to the current JBossMQ implementation. > Where have you been the past year when Adrian and Scott have been fixing this buggy MQ implementation? You failed to keep up the old stuff so please don't make it sound like you're coming to the rescue. I'm not so sure I want a total refactoring of the old JMS in the remoting subsystem and the interceptor chains and such. The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. What I don't want is a CVS HEAD of the old JMS that doesn't look like the 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS HEAD that has been totally refactored. The old JMS needs to live a bit beyond 4.0's release and 4.0 will not be released until the late late fall, between Thanksgiving and Christmas. I guess what I'm saying is that a lot of users will still depend on the old JMS for at least another year and we need some to have fluidity between 3.2 and 4.0. We're already experiencing the pain of an unnecessary rewrite of the Entity Container that is making it difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to happen with a codebase that is going to be retired eventually anyways and that needs to live in depracated mode for awhile. > Nathan, > > Your doing great work in the peer based JMS arena. But have you > formulated a game plan for the rewrite of general purpose > implementation? > > Right now I'm going down the route of simplifying our current c/s > implementation down enough so that we can start taking it apart more > easily if required to add the needed features. > If you still are up to merging fixes in 3.2 to HEAD that is fine. I'm not sure we want a full refactoring. Bill --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] DR2 Released
DR2 is finally released. Download here: http://prdownloads.sourceforge.net/jboss/jboss-4.0.0DR2.zip?download JBoss 4 Developer Release 2 Features include: * JBossDO. JDO for transperent persistence for POJOs. First iteration from the hard work of Alex Loubyansky. http://jboss.org/index.html?module=html&op=userdisplay&id=developers/project s/jboss/jbossdo * JMS rewrite. First iteration from Nathan with help from Bela Ban and Adrian Brock. P2P serverless topics by way of reliable multicast. http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/pro jects/jboss/jms * AOP XDoclet integration. Great work from Andy Godwin. JSR-175/C# metatags right now in JBoss 4! * Expand AOP Pointcuts. Per method, field, constructor as well as Caller pointcuts http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/pro jects/jboss/aop Have fun, Bill XXXX Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Freeze for DR2 Tues 9:00am EST
FYI, Freeze will be Tues, tomorrow, 9:00am EST. (When I get up ;-P ) . CVS will open again sometime tomorrow(Tuesday) or Wednesday depending on the health of HEAD. Bill Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tyrex transaction manager
They are actually one of our partners. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Fred > Hartman > Sent: Thursday, June 26, 2003 4:42 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Tyrex transaction manager > > > Maybe this is a production DTM option > http://www.arjuna.com/products/jboss/index.html although I don't know the > cost. > > Cheers, > Fred > > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 26, 2003 12:23 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Tyrex transaction manager > > > The Tyrex integration was done by Anatoly Akkerman([EMAIL PROTECTED]) > and it never reached a production quality service. Arbitrary stuff is > allowed in the codebase for experimentation, we only support production > level efforts that are maintained. > > -- > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > Bruce Snyder wrote: > > > This one time, at band camp, Bill Burke said: > > > > BB>We will not be supporting the Tyrex transaction manager > anymore unless > you > > BB>want to take over the integration. > > > > I'm just curious, why was this decision made? Who used to maintain > > this integration? > > > > Bruce > > > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tyrex transaction manager
Anatoly Akkerman was maintaining it a lnnng time ago. Nobody really
uses it or used it. I think the project is dead since their last release
was May 2002 and they only have one CVS committer.
http://sourceforge.net/projects/tyrex/
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Bruce
> Snyder
> Sent: Thursday, June 26, 2003 11:10 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Tyrex transaction manager
>
>
> This one time, at band camp, Bill Burke said:
>
> BB>We will not be supporting the Tyrex transaction manager
> anymore unless you
> BB>want to take over the integration.
>
> I'm just curious, why was this decision made? Who used to maintain
> this integration?
>
> Bruce
> --
> perl -e 'print
> unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E
>
>
> ---
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tyrex transaction manager
We will not be supporting the Tyrex transaction manager anymore unless you want to take over the integration. Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf > Of Oleg V. Safonov > Sent: Thursday, June 26, 2003 10:12 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Tyrex transaction manager > > > After deploy tyrex-tm-plugin I get next exception > java.lang.IllegalStateException: The transaction is not yet or no longer > active > > 2003-06-26 18:34:08,733 ERROR [org.jboss.ejb.EntityContainer] Starting > failed > java.lang.IllegalStateException: The transaction is not yet or no longer > active > at tyrex.tm.impl.TransactionImpl.enlistResource(TransactionImpl.java:600) > at tyrex.tm.impl.TransactionImpl.enlistResource(TransactionImpl.java:565) > at > org.jboss.resource.connectionmanager.TxConnectionManager$TxConnect > ionEventLi > stener.enlist(TxConnectionManager.java:460) > at > org.jboss.resource.connectionmanager.TxConnectionManager.managedCo > nnectionRe > connected(TxConnectionManager.java:358) > at > org.jboss.resource.connectionmanager.BaseConnectionManager2.alloca > teConnecti > on(BaseConnectionManager2.java:490) > at > org.jboss.resource.connectionmanager.BaseConnectionManager2$Connec > tionManage > rProxy.allocateConnection(BaseConnectionManager2.java:798) > at > org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(Wr > apperDataS > ource.java:102) > at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:39) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.(JDBC > EntityBrid > ge.java:119) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(J > DBCStoreMa > nager.java:438) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreMan > ager.java: > 372) > at > org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceMa > nager.java > :170) > at org.jboss.ejb.EntityContainer.startService(EntityContainer.java:339) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) > at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl > .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispat > cher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceCont > roller.jav > a:966) > at $Proxy11.start(Unknown Source) > at org.jboss.system.ServiceController.start(ServiceController.java:392) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl > .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispat > cher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) > at $Proxy37.start(Unknown Source) > at org.jboss.ejb.EjbModule.startService(EjbModule.java:329) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) > at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl > .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispat > cher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceCont > roller.jav > a:966) > at $Proxy11.start(Unknown Source) > at org.jboss.system.ServiceController.start(ServiceController.java:392) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl > .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispat > cher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) > at $Proxy
[JBoss-dev] FW: DR2 Freeze on Monday
Didn't see this mail come up yet so, I'll forward again. > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2003 1:16 AM > To: [EMAIL PROTECTED] > Subject: DR2 Freeze on Monday > > > We will be releasing DR2 next week so there will be a CVS freeze > on Monday, June 30th, so that we can stabalize the build. As > soon as the testsuite is stable enough and we create the release, > we will open CVS again. Unless something is drastically wrong, > this should only take 1 day. > > BTW, DR2 release will have: > > - JBoss AOP XDoclet Integration. JSR-175 in the present with JDK > 1.4 and JBoss AOP. From the hard work of Andy Godwin. > - 1st iteration of JDO. Thanks to Alex Loubyansky. > - 1st iteration of JMS rewrite. Not full-featured yet, but will > run JMS over multicast through JavaGroups. In other words, no > app-server middleman for high performance and scalability. > Thanks to Nathan Phelps with help from Bela Ban, Tom Elrod, and > Adrian Brock. > - Expanded pointcuts in AOP framework. per-method, field, and > constructor chains. > - Improved AOP framework performance. > > Thanks for your cooperation, > > Bill > > > Bill Burke > Chief Architect > JBoss Group, LLC > > > Cast your vote for JBoss as JDJ Best App Server > > http://www.sys-con.com/java/readerschoice2003/vote.cfm > --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] org\mortbay\start\Main.java:512
scott just fixed this. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Alexey Loubyansky > Sent: Saturday, June 21, 2003 7:55 AM > To: jboss-dev > Subject: [JBoss-dev] org\mortbay\start\Main.java:512 > > > I just checked out Branch_3_2 and couldn't compile. Does anyone get > the following error? > > Win2K / Sun JDK1.3.1_05 > > D:\cvsroot\jboss-3.2\jetty\src\main\org\mortbay\start\Main.java:51 > 2: start() is > inherited from java.lang.Thread and hides method in outer class > org.mortbay.star > t.Main. An explicit 'this' qualifier must be used to select the > desired instanc > e. > start(); > ^ > 1 error > 3 warnings > > Thanks, > alex > > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeremy Boynes > Sent: Saturday, June 21, 2003 4:58 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Deadlock issue with SQL Server and other > databases > > > > > > Are you sure this couldn't be avoided by using Instance Per > Transaction + > > SERIALIZABLE + Commit C? > > > > If you think about it, you'd realize that this just pushes the > deadlock into > the database resulting in rollbacks. This is the multi-instance model > described in the spec, but is not the way JBoss is configured by default. > > I happen to think making the default configuration multi-instance > would be a > little more disruptive than making the single-instance config we use now > work correctly. > We've been doing multi-instance since JBoss 2.4. Many customers and users use this feature successfully. > > If so, I'm worried that if you expand row-locking to happen > > during finder queries, you'll break a lot of applications. > > That would be the same concern I expressed in the original post ;-) > Again, since 2.4 > But again, row-locking is meant to imply locking. The bug is that we only > actually do it on the queries issued by LoadEntity and > LoadRelation, and not > on all the queries we execute. This leads to inconsistent locking and > ultimately, the deadlock. > > If people wish to use READ_COMMITTED, then simply don't turn on > row-locking. > But users use it that way. Since we don't have a distributed entity cache in 3.2, they use READ-COMMITTED + row-locking in a cluster. In fact there is no reason to use row-locking when you're using commit-option 'A' anyways since JBoss handles the locking. So why change things? Again, instance-per-transaction + SERIALIZABLE + Commit B or C gives you the same behavior doesn't it? > > > > We do have a mechanism to denote read-only invocations, at least on the > > Entity Bean level. > > Do we? I thought we only had read-only flags at the entity and > method level, > and they do not cover the dynamic nature of the usage. For example, when I > call findByPrimaryKey, I may be intending to just read from the > returned EJB > or to update some values; the future usage determines the type of lock to > take during the query. > > > I would like a plan from you on what kind of metadata > > needs to flow within the context of an invocation. I have done > > some work on > > how contextual information should flow throughout the system > with the AOP > > framework, but it probably needs to be expanded. A usecase > from you would > > help in this arena. > > > See above > You can only define read-only methods for Entity beans, but there's no reason we couldn't expand it to Session beans. Push and pop read-only in a thread local. There's some use cases for this to optimize ECPerf better as well. This should really be a JB4 thing though and really a separate issue > > Do not commit this change into the 3.2 branch until it has been fully > > documented by you within HEAD and fully reviewed by the > > community. We have > > to be very careful on how we apply fundamental changes to a maintainence > > release like 3.2.x. Other wise we may hinder our users from > > upgrading to a > > higher maintainence release because something as fundamental as > > locking has > > changed. > > > > The purpose of the original post _was_ to bring this to the > attention of the > community. > > This is a bug fix, not a fundamental change or conflicting > enhancement, and > is entirely appropriate for a maintenance release (at least Scott and I > thought so). Not fixing bugs in a timely manner is a hurdle to adoption in > general and not what one expects from an open source project. > Bug fixing is one thing, but changing fundamental behavior is another. Row-locking has been around since 2001 when I committed it to CVS. Some users rely on the fact that finder calls do not lock when row-locking is set. Ok, I reread your post and as I understand it you just want to add FOR UPDATE(or equivalent) to sql in the CMP engine. I was a bit worried you were going to change the app-server-level locking schemes too. Still, users are a bit touchy when it comes to locking. Again, SERIALIZABLE + instance per-transaction + commit B/C should work, shouldn't it? And again, row-locking is not used with commit option 'A'. Sorry to be nit-picky, but I want to avoid another flood of locking questions yet again. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeremy Boynes > Sent: Saturday, June 21, 2003 12:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] Deadlock issue with SQL Server and other databases > > > This bug indicates how a deadlock can occur between two threads > reading and > writing the same data: > http://sourceforge.net/tracker/index.php?func=detail&aid=758108&gr > oup_id=228 > 66&atid=376685 > > This is a hybrid deadlock where one thread gets blocked in the > database and > the other in the app server. As a result neither systems' > deadlock detection > works and the application hangs until the transaction times out. > > This can happen when: > * The database uses shared-read (S) locks on read and exclusive (X) locks > on writes. > * The database retains S locks for the duration of the transaction; for > example, if the database isolation level is raised to SERIALIZABLE > * The application reads data from the database before modifying it > Are you sure this couldn't be avoided by using Instance Per Transaction + SERIALIZABLE + Commit C? > The row-locking option in CMP is meant to avoid such issues by > ensuring the > rows being read are locked so that updates can be performed > later. However, > this option only affects the query executed for ejbLoad, and not other > queries such as finders. > > I will be fixing this in 3.2 and HEAD by ensuring that the row-locking > option affects all queries executed by the CMP engine. This will cure the > deadlock scenario described in the bug, but may impact the application: > Now does your deadlock scenario only happen with Isolation level SERIALIZABLE? If so, I'm worried that if you expand row-locking to happen during finder queries, you'll break a lot of applications. If your deadlock scenario is only under SERIALIZABLE I suggest we investigate having metadata that can mark the transaction isolation level of the database connection so that we can avoid doing a lock during finder queries for READ_COMMITTED isolation levels and lower. It is my experience that the general use of JBoss and DBs is with READ_COMMITTED isolation. I'd hate to see concurrency suffer under READ_COMMITTED scenarios just to obtain completeness when the isolation level is SERIALIZABLE. Let's make sure that this doesn't happen. > * If two threads read data in different orders, then a deadlock can > occur at the database level; this is currently true at the EJB > level anyway. If this happens, the database's deadlock detection > may cause one query to be terminated (SQL Server does this) > resulting in rollback > > * Because all data is locked on read, concurrency will be reduced. > This is the expected behaviour for applications running at a > SERIALIZABLE isolation level. For those databases that support > it (e.g. SQL Server), I will try and make row-locking use update > locks rather than exclusive locks to allow reader threads to > proceed. However, without a mechanism to denote read-only > invocations, this may not have tangible benefit. > We do have a mechanism to denote read-only invocations, at least on the Entity Bean level. I would like a plan from you on what kind of metadata needs to flow within the context of an invocation. I have done some work on how contextual information should flow throughout the system with the AOP framework, but it probably needs to be expanded. A usecase from you would help in this arena. > I am posting this to the lists early as a heads-up of a change in > behaviour > as a consequence of fixing this bug. A change note will be posted when the > fix is committed. > Do not commit this change into the 3.2 branch until it has been fully documented by you within HEAD and fully reviewed by the community. We have to be very careful on how we apply fundamental changes to a maintainence release like 3.2.x. Other wise we may hinder our users from upgrading to a higher maintainence release because something as fundamental as locking has changed. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Attn: Sacha - AbstractSessionManager changes in org.mortbay...
Give us CVS access and we will be happy to merge these changes ourselves. BIll > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jules > Gosnell > Sent: Wednesday, June 18, 2003 9:32 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] Attn: Sacha - AbstractSessionManager changes in > org.mortbay... > > > Sacha, > > I note that you have made some changes to > > jetty/src/main/org/mortbay/jetty/servlet/AbstractSessionManager.ja > va et alia > > on Branch_3_2, to support statistics retrieval. > > This is just to remind you that, whilst a copy of Jetty cvs is kept in > JBoss cvs (Marc asked for it), the place for such changes is Jetty cvs - > otherwise they will be lost next time I merge across. > > I will talk to Greg about adopting them into Jetty cvs. > > Cheers, > > > Jules > -- > > /* > * Jules Gosnell > * Partner > * Core Developers Network (Europe) > * http://www.coredevelopers.net > */ > > > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] large remoting commit
This is really great stuff Tom. You guys do great work. Some other things that need to get done in the future: 1. Have SOAP transport work as a servlet within web-container 2. Develop a broadcast abstraction so that we can integrate multicast libraries like JavaGroups. It would be cool if you could still handle the classloading on received multicast messages. 3. Setup an initialization process the first time a client connects to a URI in which the client asks the server for any transport interceptors or other services like the DTM that must be installed. This will alleviate some of the initialization mess that is on the client right now 4. Investigate on whether the same Interceptor and Invocation class can be used for Remoting, AOP/EJB. This may simplify some code and maybe avoid some unnecessary object creations. I'll probably be looking into 3 and 4. I'll run the changes by you before I commit anything to make sure I'm not interfering with any of your plans. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tom > Elrod > Sent: Wednesday, June 18, 2003 12:11 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] large remoting commit > > > I just completed a fairly large checkin to fix some remoting bugs (mostly > related to callbacks) and to add some new features, like being > able to call > directly on local server instead of having to go through a transport layer > (which again is really mostly related to callbacks). > > Everything is compiling and my remoting tests are working. However, I am > unable to test all the other subprojects that might be affected. > Only code > changed outside of remoting and jmx was the > InvokeRemoteInterceptor class in > the aspect package, which was minor. Below is a list of all the changes I > have made. > > -Tom > > > 1.Changed Client class to automatically generate a session id > (which is a > GUID), so ensures it is unique (which is a requirement for the callbacks). > Since there are several places within the jmx package that seemed to be > setting the session id explicitly with values that need to be preserved, I > have added a getter/setter method for the session id and am calling the > setter before calling the invoke method on the client. > > [Nathan, this will solve the problem you had to fix locally where > you could > not make multiple calls to the socket server because the socket connection > had been closed. The problem was when removing the callback > handler on the > server side, it could not find the handler in the collection since the id > originally sent to the server was null, then was later populated > with a real > id (in your test case being "1").] > > 2.Added retry logic to the SocketClientInvoker to do one > retry if socket > error trying to call on server. Will disconnect the socket pool and retry > one time. If still errors on second try, throws ConnectionFailedException > (as it did before). > > 3.Changed the hashCode() method of InvokerLocator class to > calculate the > hash code based on the locator's uri each time the hashCode() method is > called. If variable for hash code set in the constructor, and create two > locators with the exact same String, the hash codes were different, thus > causing problem finding corresponding server invoker for the same client > invoker locator within the InvokerRegistry. > > 4.Changed the Client to not take a session id as parameter to > invocations. > It can still be explicitly set if need to be, but by default uses an > internally generated session id. > > 5.Added constants to the InternalInvoker class for the > internal methods > (i.e. addClientListner, removeClientListener, getCallbacks, > handleCallbacks, > addListener, removeListener()) > > 6.Removed getId(), getCallbacks() and destroy() from the > InvokerCallbackHandler interface > > 7.Changed the logic of the handling of InvokerCallbackHandlers to be > internal to the remoting framework. This means that the > subsystem handlers > will no longer be responsible for dealing with the handleCallback() > invocations and passing onto their callback handlers. This is now done > internally by the ServerInvoker class. > > 8.Changed the throws from Exception to HandleCallbackException in the > InvokerCallbackHandler's method handleCallback(). > > > Remaining TODO's > > 1.Need to make a fixed size list for storing the pull callbacks within > ServerInvokerCallbackHandler. Currently this is just an ArrayList, so > possible to run out of memory if client never calls to get the callbacks. > 2.Need a way of realizing when client is dead, so can cleanup > listener and > callbacks on the server side. > 3.What parameter(s) should the handleCallback() method of > InvokerCallbackHandler interface take? Currently InvocationRequest, which > makes it very generic, but has no real meaning within callback context. > > > >
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Tuesday, June 17, 2003 2:16 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > > On Monday, June 16, 2003, at 10:57 PM, Bill Burke wrote: > > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] Behalf Of > >> David > >> Jencks > >> Sent: Monday, June 16, 2003 12:32 AM > >> To: [EMAIL PROTECTED] > >> Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > >> deployment > >> > >> > >> I've modified the deployment system to allow for multiple xml > >> deployment descriptors. XSLSubDeployer can be configured via the > >> Properties valued DdNameToKeyMap property to import the specified dds > >> and store them in the DeploymentInfo under the specified key. The > >> properties lines look like =KEY. > >> > >> I've also added the new DeploymentInfoURIResolverFactory which can > >> resolve uris to documents in the current deployment info or documents > >> in other DeploymentInfo mbeans. URIs are of the form > >> jboss-di://##. The > >> deployment-info-name and xpath-expression are optional. The > >> DeploymentInfoDocumentURIResolver is now obsolete. I've discovered > >> that use of two # characters in a URI is ungrammatical so the first > >> will be changed to ! shortly. > >> > > > > If we're moving to a meta object model, > > I'm not convinced we are, I am unconvinced anything more than mbeans is > necessary. Configuring mbeans that do the work directly has the nice > property that you can see and change what the properties are directly > in the jmx console. > That's a nifty idea, but until we get a JMX console that can display hierarchical data, pretty much useless. I'd like to see a better scheme to render the current JMX components before this idea is explored. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Tuesday, June 17, 2003 2:32 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > On Tuesday, June 17, 2003, at 12:58 AM, Bill Burke wrote: > > > Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 > > descriptors in 4.0? I'd much rather a 3.2 component crap out > > gracefully in > > 4.0 than have to maintain 3 separate configuration mechanisms. > > I wish we could get rid of the old stuff, but it is a requirement of > the EJB 2.1 specification that we support 2.0 and 1.1 deployment > descriptors. Also, one of the common complaints of the JBoss project > is the changing of deployment descriptors and the lack backward > compatibility. With XSL we can build the code to support on version > and use style sheets to up convert old stuff. > > > I do like the idea of having a metamodel separate from XML parsing. > > BUT > > STILL, it is quite easy to navigate the current metadata/XML marriage > > that > > now exists in current configuration. Are you sure we're actually > > gaining > > any maintainability by changing the status quo? > > I thought one of Scott's requirements was to remove reliance on XML in > the metadata model for 4.0. Scott? > I would rather have a separate migration tool than to actually provide the ability to deploy older versions of JBoss. Or even better, deployers that actually tell you what is wrong with the XML you're deploying rather than getting some barf from a DTD validator or XSL transformer. Old code should be getting simpler and smaller with age as it gets refactored. I get a little wary when I see people writing abstractions for the simplest of things. Bill > -dain > > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Tuesday, June 17, 2003 2:35 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > On Tuesday, June 17, 2003, at 12:36 AM, Bill Burke wrote: > > > Why? Because everybody is very familiar with them. Why? because its > > simple > > and easy to maintain and modify. Yes, the XML parsing needs to be > > moved to > > a separate module, but the classes themselves have held up fine. I > > will not > > allow you to add anything overly complex like the mess you did with > > datasources. David, you have never ever built a piece of software for > > JBoss > > that was even remotely intuitive to configure. Configuration is not > > your > > strength so please STAY AWAY from it. I'm warning you. If I see an > > XSLT > > translation anywhere within EJB land I will roll it back. > > Can we please dial back the personal and emotional issues and return to > objective discussions of the technology? > XSLT translations in EJB land will be rolled back. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, June 16, 2003 12:32 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > I've modified the deployment system to allow for multiple xml > deployment descriptors. XSLSubDeployer can be configured via the > Properties valued DdNameToKeyMap property to import the specified dds > and store them in the DeploymentInfo under the specified key. The > properties lines look like =KEY. > > I've also added the new DeploymentInfoURIResolverFactory which can > resolve uris to documents in the current deployment info or documents > in other DeploymentInfo mbeans. URIs are of the form > jboss-di://##. The > deployment-info-name and xpath-expression are optional. The > DeploymentInfoDocumentURIResolver is now obsolete. I've discovered > that use of two # characters in a URI is ungrammatical so the first > will be changed to ! shortly. > If we're moving to a meta object model, please tell me why we need point pointers into the documents of different deployments? Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Scott > M Stark > Sent: Monday, June 16, 2003 11:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > The XSLSubdeployer is acting as an interceptor and a deployer. > The transformation > activity needs to be factored out from the subdeployer behavior. > It makes no sense > to add subdeployers that really do not deploy anything simply to > achive the side effect > of an interceptor. > > Futher, the deployers need to stop dealing with the descriptor > xml document parsing > and instead operate on the descriptor metadata object model. This > allows for a 4.0 > deployer to deal with previous version deployment decriptors as > the transformation > from 3.0, 3.2, 4.0 deployment descriptors to the current > deployment metadata is > done outside of the deployer by a filter. > Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, June 16, 2003 8:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb > deployment > > > > On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: > > > This is not consistent with the move to extract the metadata parsing > > from the current > > deployers into filters or interceptors associated with the deployers. > > The key issue is > > to support transformation of multiple versions of the various > > descriptors into metadata > > used by the current deployer. > > Please explain your point of view. The XSLSubdeployer IS an > interceptor. This change is in the direction of allowing a single > chain of subdeployers that can deploy anything. Why would we want to > preserve the current ejb metadata classes? Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Guys guys! These are configuration files! We're doing something seriously wrong here if we're doing XSLT transformations and jumping through hoops just to configure a bit of metadata. The implementation of configuration needs to be simple enough so that the casual JBoss contributor can easily add his/her little configuration tweak. All you're doing by adding all these configuration abstractions is putting up barriers for new developers. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
I'm pretty excited about the JavaGroups implementation. Should scale quite well. I also really liked the idea of the AppServer being just another subscriber for durable topics. Should be interesting how all this develops over the next few months. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bela > Ban > Sent: Monday, June 16, 2003 2:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > Bill Burke wrote: > > > Nathan's design will not be based on JavaGroups, but will rather use > > JavaGroups as one type of transport mechanism. > > > Don't get all nervous; that's what I meant. 2 transports, one is the > traditional c/s, the other one is implemented using JavaGroups. > > > > I would rather see JBoss Remoting used as an abstraction with > > JavaGroups as a plugin rather than > > JavaGroups at the center of things. > > > Tom, Jeff, Nathan and I have tentatively scheduled JBoss bootcamp in > Atlanta to be the place and time for an in-depth discussion of whether > Remoting can accommodate a one-to-many paradigm in addition to a > one-to-one paradigm. > > Nathan already has a thin abstraction layer over the transport, for both > traditional and serverless design. > > > -- > Bela Ban > http://www.javagroups.com > Cell: (408) 316-4459 > > > > --- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. BUTdon't let this requirement hold you up from getting a first iteration in place. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bela > Ban > Sent: Monday, June 16, 2003 1:12 PM > To: [EMAIL PROTECTED] > Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > > Hi Ulf, > > > (2) message redelivery / message throttling clustering / failover > > > since Nathan's design is based on JavaGroups, these issues are > JavaGroups issues: > - Message retransmission is handled by JavaGroups. > - Failover: what do you understand by failover ? > - Throttling: we are working on a multicast flow control protocol, JG > currently ships with one, but it has a number of bugs and needs further > work. I'm also working on a new flow control protocol. Also, note that > you can run JG with TCP as transport, then you essentially have the > classic JMS client-server implementation. > > > > (3) messaging system monitoring / administration > > > > I there a way to participate in the your ongoing rewrite ? > > > Give us some more time; Nathan essentially designed the serverless JMS > last weekend... > > > -- > Bela Ban > http://www.javagroups.com > Cell: (408) 316-4459 > > > > --- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] O'Reilly JBoss 3.2 workbook
Whoops, it would be nice if I gave the actuall URL. 3.2 Workbook is free BTW. http://www.oreilly.com/catalog/entjbeans3/workbooks/index.html Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bill > Burke > Sent: Friday, June 06, 2003 5:59 PM > To: Jboss-Dev; JBoss 2 > Subject: [JBoss-dev] O'Reilly JBoss 3.2 workbook > > > The Title still says 3.0, but the O'Reilly 3.2 companion workbook for > O'Reilly 3rd edition. Look for more stuff with O'Reilly in the future. > > Best regards, > > Sacha and Bill > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] O'Reilly JBoss 3.2 workbook
The Title still says 3.0, but the O'Reilly 3.2 companion workbook for O'Reilly 3rd edition. Look for more stuff with O'Reilly in the future. Best regards, Sacha and Bill --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] head is open
Should have announced Sunday night, but head is open again. Bill Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] No more HEAD CVS commits until Monday!!
I'll be preparing our DR1 release 7:00 p.m. tonight. If you absolutely have to commit something please email me or get on MSN Messenger. Thanks, Bill Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] releasing on Sunday
Sorry Francisco, this is my fault. I put the InvocationResponse stuff in. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Francisco Reverbel > Sent: Wednesday, May 28, 2003 5:20 PM > To: Jboss-Dev > Subject: Re: [JBoss-dev] releasing on Sunday > > > Replying to my own message before anybody else spends time on this... > > On Wed, 28 May 2003, Francisco Reverbel wrote: > > > All IIOP tests fail in the 4.0 branch. Does anybody know why? > > I thought there were no IIOP changes in head since it was branched > > off 3.x. > > This was the problem. There should have been some IIOP changes, since > the invoker interface changed (invoke now returns an InvocationResponse). > > Commiting a fix... > > Francisco > > > > > There are some IIOP fixes in 3.2 that need to be merged into head. > > Following the usual "test before, test after" procedure, I run > > the tests before doing it, only to find out that IIOP was already > > broken. :-( > > > > Cheers, > > > > Francisco > > > > > > On Tue, 27 May 2003, Bill Burke wrote: > > > > > We'll be doing the DR1 release on Sunday. Please ask Scott > or me before > > > committing. We'll be more and more reluctant to allow > commits as we get > > > closer. We should be stabalizing not adding new features at the last > > > minute. > > > > > > Thanks, > > > > > > Bill > > > > > > > > > Bill Burke > > > Chief Architect > > > JBoss Group, LLC > > > > > > > > > Cast your vote for JBoss as JDJ Best App Server > > > > > > http://www.sys-con.com/java/readerschoice2003/vote.cfm > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: ObjectStore. > > > If flattening out C++ or Java code to make your application fit in a > > > relational database is painful, don't do it! Check out ObjectStore. > > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] releasing on Sunday
We'll be doing the DR1 release on Sunday. Please ask Scott or me before committing. We'll be more and more reluctant to allow commits as we get closer. We should be stabalizing not adding new features at the last minute. Thanks, Bill XXXX Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26]
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Nathan Phelps > Sent: Friday, April 04, 2003 10:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline > MAY 26] > > > I question if A JMSServerInvocationHandler is even necessary (along with > the JMS Subsystem) if Bill exposes the callbacks via the AOP remoting > framework. Frankly, I have the same thought about all the "subsystems" > as I know EJB for instance will also being using the AOP framework and > therefore the AOPServerInvocationHandler. I know you guys have a JMX > subsystem which you have used to implement JMX remoting, but if you > decide to refactor that to use the AOP framework that subsystem wouldn't > be necessary either as far as I understand it. What I'm getting at is > that it is my understanding that the future of J2EE flavored services on > JBoss will be built on top of the AOP framework, and therefore AOP > remoting is going to be the only InvocationHandler used because it is > what gives us the modern interceptor stack. > > Bill, am I correct? > I'm not sure yet. I hope JMX and AOP and everybody else could use the same Invocation object and Interceptor interfaces, but JMX may have other requirements that require its own Handler. Iteration will allow us to explore the possibilities. > Thanks, > > Nathan > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom > Elrod > Sent: Friday, April 04, 2003 1:05 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline > MAY 26] > > Guess Jeff beat me to it ;) > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Tom > > Elrod > > Sent: Friday, April 04, 2003 1:49 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline > > MAY 26] > > > > > > Jeff made the fix last night and I have not looked at the > > code yet (he still > > has it local while we are testing that and some other fixes > > out). However, > > my understanding from Jeff is that the invoker client passes > > its locator to > > the invoker server if it wishes to receive callbacks. The > > invoker server > > will then use that for establishing the connection back to > > the client to > > send notifications (callbacks). > > > > Given this, it will be pretty easy to make it so the calling > > code can give > > the client invoker the locator to use for callbacks, which it > > then gives the > > invoker server (and will use its own by default as is now). > > I can put this > > in this weekend (if Jeff doesn't beat me to it). > > > > It sounds like there won't be enough time to include JMS as one of the > > invoker transport before the deadline. However, I would personally be > > interested in working with you on it. Depending on how soon > > you will have > > time to start on it, might be wise to make a branch just for the JMS > > transport, until JB4DR1. > > > > -Tom > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > Nathan Phelps > > > Sent: Thursday, April 03, 2003 11:44 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > > > > Did you guys end up doing it in such a way so that you can use one > > > protocol one way and another protocol the other way like you had > > > mentioned? > > > > > > Secondly, what is really going to be cool when we expose > > this via AOP > > > remoting... Bill, what are your plans for that? > > > > > > Thanks, > > > > > > Nathan > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Jeff > > > Haynie > > > Sent: Thursday, April 03, 2003 8:21 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > Jboss Remoting callbacks are in - I wil commit in the next day or so > > > when tom and I finish testing. > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Bill > > > Burke > >
RE: [JBoss-dev] Oswego util.concurrent jar updated
LOL > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Scott > M Stark > Sent: Thursday, April 03, 2003 5:02 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Oswego util.concurrent jar updated > > > I updated the Oswego util.concurrent jar in 3.0+ from the rather > ancient 1.3.0 > version to 1.3.2 as we found some serious concurrency failures in the > ConcurrentHashMap and ConcurrentReaderHashMap classes in looking into > some JMS load test failures. A bit ironic that the concurrent > package was messing > up concurrency. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
I'm ok with JMS. I didn't think you could rewrite in such short of time. Especially with Remoting and AOP just now becoming stable. I think this email thread is good because it will allow us to determine whether or not we can release. I still think there is enough functionality. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Nathan Phelps > Sent: Thursday, April 03, 2003 5:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > I agree that there is some great stuff in there already. However, being > that the AOP transaction, security, remoting, etc. was only recently > released in its first iteration, and the fact that JBoss remoting > doesn't yet support true callbacks (Jeff says it is coming) there is > simply no way I can deliver the new JMS implementation BUILT ON TOP of > these services by May 5th! And I'm going to be out basically two weeks > between now and then with customers as I know others will be as well. > > Since the whole point of the JMS rewrite is to take advantage of the > core JBoss AOP services, I haven't really had that much time to do so > since the services have only recently been released. Therefore, I > expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE which > is currently in HEAD. It is the only option with a May 5th deadline in > my opinion. If everyone is OK with this and we're committed to that > date, then I am must immediately shift my attention from the development > of the new code build on top of the AOP framework to the old code > currently in HEAD to start working on ensuring JMS 1.1 compliance, > stability, etc. as well as applying the HTTP IL code currently only in > Branch_3_2 to HEAD. Then, after the May 26th release, I'll continue > working on the new JMS code which is build on top of the AOP framework. > > Comments? > > Thanks, > > Nathan > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill > Burke > Sent: Thursday, April 03, 2003 3:22 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > There's already a lot we can release. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > Dain > > Sundstrom > > Sent: Thursday, April 03, 2003 4:01 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > I think you are delusional if you think JB4 will be ready for JavaOne. > > > > -dain > > > > On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > > > > > Guys, > > > > > > We are thinking a lot about the forthcoming JB4 release. It is a > truly > > > exciting step for us as we believe we will bring a programming > style, > > > whose time has come, to a mass audience. > > > > > > AOP as Bill says is a clear wave for system level services on par > with > > > OOP. On top of it and also as a proof of how powerful the approach > is > > > we still develop a full J2EE server. Meaning that you can choose to > > > live in the J2EE world work on JBoss J2EE and access all the > > > prepackaged > > > AOP goodies as you have been doing since JBoss2.0. > > > > > > There seems to be a lot of fear at SUN from what I can tell in the > > > press, that we will abandon J2EE. We love J2EE. When really we will > > > support J2EE for the forthcoming future. Never do we talk about > > > "abandoning" J2EE, we just let the user access core functionality in > > > > the > > > open server and think at the AOP level. A more fundamental > construct > > > of > > > the framework. > > > > > > The reason we are almost there is that it is also a very old > > > implementation in JBoss. We have been doing it for a long time but > > > never talked/packaged it this way. We make it easy for you to > leverage > > > the AOP layer. The implementation is old the way you interact with > > > JBoss > > > is new. It can also be old if you decide to stay at the J2EE level > > > which will be fully supported. > > > > > > But you are now invited to roam in the core JBoss system, in fact > you > > > may find it very cozy as you port POJO based applications to JBoss. > > > There will be a stabilization period though. We are making an > > > aggressive push to release JB4 by JavaONE with all our resources > > > dedicated to
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
1.3 Some 1.4 stuff will probably sneek in though. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Igor > Fedorenko > Sent: Thursday, April 03, 2003 5:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > What J2EE specification version are you planning to support in > JBoss 4.0? J2EE 1.4 is not final as far as I know... > > > -Original Message- > > From: marc fleury [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 03, 2003 3:47 PM > > To: [EMAIL PROTECTED] Sourceforge. Net > > Subject: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > Guys, > > > > We are thinking a lot about the forthcoming JB4 release. It > > is a truly > > exciting step for us as we believe we will bring a programming style, > > whose time has come, to a mass audience. > > > > AOP as Bill says is a clear wave for system level services on par with > > OOP. On top of it and also as a proof of how powerful the approach is > > we still develop a full J2EE server. Meaning that you can choose to > > live in the J2EE world work on JBoss J2EE and access all the > > prepackaged > > AOP goodies as you have been doing since JBoss2.0. > > > > There seems to be a lot of fear at SUN from what I can tell in the > > press, that we will abandon J2EE. We love J2EE. When really we will > > support J2EE for the forthcoming future. Never do we talk about > > "abandoning" J2EE, we just let the user access core > > functionality in the > > open server and think at the AOP level. A more fundamental > > construct of > > the framework. > > > > The reason we are almost there is that it is also a very old > > implementation in JBoss. We have been doing it for a long time but > > never talked/packaged it this way. We make it easy for you > > to leverage > > the AOP layer. The implementation is old the way you interact > > with JBoss > > is new. It can also be old if you decide to stay at the J2EE level > > which will be fully supported. > > > > But you are now invited to roam in the core JBoss system, in fact you > > may find it very cozy as you port POJO based applications to JBoss. > > There will be a stabilization period though. We are making an > > aggressive push to release JB4 by JavaONE with all our resources > > dedicated to implementing the final AOP system aspects and > > porting some > > of the existing code to that. > > > > We're making an aggressive push to release JBoss 4.0 by > > JavaOne. We're > > targeting May 26th. That leaves us 2 month from now. > > > > I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH > > > > > > To meet this aggressive deadline, we need to set some dates. > > There will > > be a functionality freeze, Monday, May 5th. All new functionality > > commits after May 5th must be approved by either Scott Stark, or Bill > > Burke. We will not branch May 5th, but instead make the month of May, > > JBoss 4.0 stability en route to a Developpers Release 1 (DR1). > > > > Please think long and hard and fast about your modules. Many > > of you are > > involved in core modules that need to move fast in the coming weeks. > > Don't be afraid to talk and say who needs help etc. > > > > PLgC > > > > marcf > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
JBoss Remoting AOP + tx, security, versioning, remoting, clustering, txlock, caching DTM (waiting on David's response) EMB (Enterprise Media Beans) JUDDI integration If I can get it done: AOP + EJB (packaged extensions to EJB) and don't forget Nukes! Anybody got anything to add to this list? Who doesn't think they'll be done by May 5th? Who thinks they'll be cutting it close? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Thursday, April 03, 2003 4:48 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > Ok then there are 4 weeks to get the new stuff done? > > Marc, Bill, sure we could do a release but what difference would it > make if the new features are not in it. Is this a release just to show > off AOP? What about any of the other new stuff? > > Just give the users a solid 3.2 and they will be happy. > > -dain > > On Thursday, April 3, 2003, at 03:30 PM, Bill Burke wrote: > > > It will be ready and stable. Functionality freeze is May 5th. What > > functionality doesn't make it by then will be left out of the release. > > > > Bill > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] Behalf Of > >> Dain > >> Sundstrom > >> Sent: Thursday, April 03, 2003 4:01 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > >> > >> > >> I think you are delusional if you think JB4 will be ready for JavaOne. > >> > >> -dain > >> > >> On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > >> > >>> Guys, > >>> > >>> We are thinking a lot about the forthcoming JB4 release. It is a > >>> truly > >>> exciting step for us as we believe we will bring a programming style, > >>> whose time has come, to a mass audience. > >>> > >>> AOP as Bill says is a clear wave for system level services on par > >>> with > >>> OOP. On top of it and also as a proof of how powerful the approach > >>> is > >>> we still develop a full J2EE server. Meaning that you can choose to > >>> live in the J2EE world work on JBoss J2EE and access all the > >>> prepackaged > >>> AOP goodies as you have been doing since JBoss2.0. > >>> > >>> There seems to be a lot of fear at SUN from what I can tell in the > >>> press, that we will abandon J2EE. We love J2EE. When really we will > >>> support J2EE for the forthcoming future. Never do we talk about > >>> "abandoning" J2EE, we just let the user access core functionality in > >>> the > >>> open server and think at the AOP level. A more fundamental construct > >>> of > >>> the framework. > >>> > >>> The reason we are almost there is that it is also a very old > >>> implementation in JBoss. We have been doing it for a long time but > >>> never talked/packaged it this way. We make it easy for you to > >>> leverage > >>> the AOP layer. The implementation is old the way you interact with > >>> JBoss > >>> is new. It can also be old if you decide to stay at the J2EE level > >>> which will be fully supported. > >>> > >>> But you are now invited to roam in the core JBoss system, in fact you > >>> may find it very cozy as you port POJO based applications to JBoss. > >>> There will be a stabilization period though. We are making an > >>> aggressive push to release JB4 by JavaONE with all our resources > >>> dedicated to implementing the final AOP system aspects and porting > >>> some > >>> of the existing code to that. > >>> > >>> We're making an aggressive push to release JBoss 4.0 by JavaOne. > >>> We're > >>> targeting May 26th. That leaves us 2 month from now. > >>> > >>> I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH > >>> > >>> > >>> To meet this aggressive deadline, we need to set some dates. There > >>> will > >>> be a functionality freeze, Monday, May 5th. All new functionality > >>> commits after May 5th must be approved by either Scott Stark, or Bill > >>> Burke. We will not branch May 5th, but instead make the month of > >>> M
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
It will be ready and stable. Functionality freeze is May 5th. What functionality doesn't make it by then will be left out of the release. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Thursday, April 03, 2003 4:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > I think you are delusional if you think JB4 will be ready for JavaOne. > > -dain > > On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > > > Guys, > > > > We are thinking a lot about the forthcoming JB4 release. It is a truly > > exciting step for us as we believe we will bring a programming style, > > whose time has come, to a mass audience. > > > > AOP as Bill says is a clear wave for system level services on par with > > OOP. On top of it and also as a proof of how powerful the approach is > > we still develop a full J2EE server. Meaning that you can choose to > > live in the J2EE world work on JBoss J2EE and access all the > > prepackaged > > AOP goodies as you have been doing since JBoss2.0. > > > > There seems to be a lot of fear at SUN from what I can tell in the > > press, that we will abandon J2EE. We love J2EE. When really we will > > support J2EE for the forthcoming future. Never do we talk about > > "abandoning" J2EE, we just let the user access core functionality in > > the > > open server and think at the AOP level. A more fundamental construct > > of > > the framework. > > > > The reason we are almost there is that it is also a very old > > implementation in JBoss. We have been doing it for a long time but > > never talked/packaged it this way. We make it easy for you to leverage > > the AOP layer. The implementation is old the way you interact with > > JBoss > > is new. It can also be old if you decide to stay at the J2EE level > > which will be fully supported. > > > > But you are now invited to roam in the core JBoss system, in fact you > > may find it very cozy as you port POJO based applications to JBoss. > > There will be a stabilization period though. We are making an > > aggressive push to release JB4 by JavaONE with all our resources > > dedicated to implementing the final AOP system aspects and porting some > > of the existing code to that. > > > > We're making an aggressive push to release JBoss 4.0 by JavaOne. We're > > targeting May 26th. That leaves us 2 month from now. > > > > I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH > > > > > > To meet this aggressive deadline, we need to set some dates. There > > will > > be a functionality freeze, Monday, May 5th. All new functionality > > commits after May 5th must be approved by either Scott Stark, or Bill > > Burke. We will not branch May 5th, but instead make the month of May, > > JBoss 4.0 stability en route to a Developpers Release 1 (DR1). > > > > Please think long and hard and fast about your modules. Many of you > > are > > involved in core modules that need to move fast in the coming weeks. > > Don't be afraid to talk and say who needs help etc. > > > > PLgC > > > > marcf > > > > > > > > xx > > Marc Fleury, Ph.D. > > President, Founder > > JBoss Group, LLC > > xx > > > > > > > > --- > > This SF.net email is sponsored by: ValueWeb: > > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > > No other company gives more support or power for your dedicated server > > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
There's already a lot we can release. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Thursday, April 03, 2003 4:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > I think you are delusional if you think JB4 will be ready for JavaOne. > > -dain > > On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > > > Guys, > > > > We are thinking a lot about the forthcoming JB4 release. It is a truly > > exciting step for us as we believe we will bring a programming style, > > whose time has come, to a mass audience. > > > > AOP as Bill says is a clear wave for system level services on par with > > OOP. On top of it and also as a proof of how powerful the approach is > > we still develop a full J2EE server. Meaning that you can choose to > > live in the J2EE world work on JBoss J2EE and access all the > > prepackaged > > AOP goodies as you have been doing since JBoss2.0. > > > > There seems to be a lot of fear at SUN from what I can tell in the > > press, that we will abandon J2EE. We love J2EE. When really we will > > support J2EE for the forthcoming future. Never do we talk about > > "abandoning" J2EE, we just let the user access core functionality in > > the > > open server and think at the AOP level. A more fundamental construct > > of > > the framework. > > > > The reason we are almost there is that it is also a very old > > implementation in JBoss. We have been doing it for a long time but > > never talked/packaged it this way. We make it easy for you to leverage > > the AOP layer. The implementation is old the way you interact with > > JBoss > > is new. It can also be old if you decide to stay at the J2EE level > > which will be fully supported. > > > > But you are now invited to roam in the core JBoss system, in fact you > > may find it very cozy as you port POJO based applications to JBoss. > > There will be a stabilization period though. We are making an > > aggressive push to release JB4 by JavaONE with all our resources > > dedicated to implementing the final AOP system aspects and porting some > > of the existing code to that. > > > > We're making an aggressive push to release JBoss 4.0 by JavaOne. We're > > targeting May 26th. That leaves us 2 month from now. > > > > I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH > > > > > > To meet this aggressive deadline, we need to set some dates. There > > will > > be a functionality freeze, Monday, May 5th. All new functionality > > commits after May 5th must be approved by either Scott Stark, or Bill > > Burke. We will not branch May 5th, but instead make the month of May, > > JBoss 4.0 stability en route to a Developpers Release 1 (DR1). > > > > Please think long and hard and fast about your modules. Many of you > > are > > involved in core modules that need to move fast in the coming weeks. > > Don't be afraid to talk and say who needs help etc. > > > > PLgC > > > > marcf > > > > > > > > xx > > Marc Fleury, Ph.D. > > President, Founder > > JBoss Group, LLC > > xx > > > > > > > > --- > > This SF.net email is sponsored by: ValueWeb: > > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > > No other company gives more support or power for your dedicated server > > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AOP security 1st iteration
Configuration is exactly like J2EE except fields and constructors are added. There's an example under the testsuite. Here's an XML snippet. java:/jaas/other allowed someMethod unchecked allowed someField uncheckedField allowed int Methods that connect be used excluded excludedField java.lang.String --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[7]: [JBoss-dev] php5 is coming
Julien, It is going to be hard enough to attract developers to Nukes, don't
make it harder by developing your own proprietary scripting language.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> julien viet
> Sent: Tuesday, April 01, 2003 7:36 AM
> To: Pavel Kolesnikov
> Subject: Re[7]: [JBoss-dev] php5 is coming
>
>
> for me no. I don't like jsp tags.
>
> PK> On Tue, 1 Apr 2003, julien viet wrote:
>
> >> I dont't want to reinvent a scripting language, but JSP are
> >> not adapted to nukes at all. I think the nicest feature of
> >> JSP is the possibility to embed true java code whithin text :
> >>
> >>
> >> <% for (int i = 0;i < 5;i++) { %>
> >> <%= i %>
> >> <% } %>
> >>
> >>
>
> PK> Ok, but what about JSTL?
>
> PK>
> PK>
> PK>
> PK>
> PK>
>
> PK> Isn't such code a bit nicer?
>
> PK> And if you want to restrict users a little bit, you can
> PK> do it with Tag Library Validators (part of JSTL specs).
>
> PK> Pavel
>
>
>
>
> PK> ---
> PK> This SF.net email is sponsored by: ValueWeb:
> PK> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> PK> No other company gives more support or power for your dedicated server
> PK> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> PK> ___
> PK> Jboss-development mailing list
> PK> [EMAIL PROTECTED]
> PK> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> --
> Best regards,
> julienmailto:[EMAIL PROTECTED]
>
>
>
> ---
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[4]: [JBoss-dev] php5 is coming
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of marc > fleury > Sent: Monday, March 31, 2003 2:21 PM > To: [EMAIL PROTECTED] > Subject: RE: Re[4]: [JBoss-dev] php5 is coming > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Bill Burke > > Sent: Monday, March 31, 2003 10:52 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Re[4]: [JBoss-dev] php5 is coming > > > > > > I'd really prefer JSP integration or integration with some > > other popular Java based web scripting. > > JSP is clearly the way to go. We will fail if we reinvent the scripting > wheel. Let people port to JBoss with existing pages. All I hear from > Julien is lame-ass whining on the compiler and such... :) I will > personally work on him in Paris :) > And considering the marketing spin is PostNuke on J2EE. I think we are the first. Bill --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Again, you have the problem of primitive types. These would require field interception which is slow. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bela > Ban > Sent: Monday, March 31, 2003 7:11 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration > > > Hiram Chirino wrote: > > > That might be a problem if you have a big object > > graph. You get a big penalty even if you only modify > > a small peice of the object graph. > > > > You could do a shallow copy by getting a snapshot of > > the fields of the object. Then wrap up the children > > objects with "Versioned.makeVersioned(child)" when > > they are accessed. The cool thing is that you would > > not have any serialization at all. I know that there > > has to be some down-sides to this approach, help me > > figure them out. > > > This essentially requires recursively wrapping all child objects > reachable from a parent with version interceptors. > I think this is what I would require for my cache, which is > tree-structured. > > Versions would be created only when needed, as we go. > > -- > Bela Ban > www.javagroups.com > (408) 316-4459 > > > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EJB conversion to AOP Interceptor and Invocation
I'll be converting EJBs and Invokers to use the new AOP Invocation and Interceptor objects/interfaces starting Wednesday. Let me know if you have any problem with this. Regards, Bill --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Trying out AOP
Igor, I couldn't replicate this. BUT...I think I may have fixed the problem. This is probably a relic, but the Instrumentor code was adding a InvocationTargetException to the throws clause of every instrumented method. I have removed this. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Igor > Fedorenko > Sent: Wednesday, March 26, 2003 12:06 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Trying out AOP > > > > You have read/write correct? > I guess that was exactly what I wanted to know ;-) > > > Javassist may not be creating the correct > > throws clauses. Can you add a test for this under the > > testsuite and under > > aop/? I will look at it after I finish my other aop work I'm doing. > Done. Added .../aop/simpleejb/SimpleBean.java EJB, > SimpleBeanInterceptor/Factory that intercepts SimpleBean methods > and SimpleBeanUnitTestCase that fails to deploy that EJB. Note > that the same EJB can be deployed successfully without interceptors. > > Btw, is there a separate target for running AOP unit tests? I had > to run run-db-tests which seems to be too wide. > > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Igor > > > Fedorenko > > > Sent: Wednesday, March 26, 2003 12:44 AM > > > To: [EMAIL PROTECTED] Sourceforge. Net (E-mail) > > > Subject: [JBoss-dev] Trying out AOP > > > > > > > > > Hi, > > > > > > I am playing around with AOP and I want to know if I am doing > > > something wrong. What I basically want is to add additional > > > behaviour to an EJB implementation. The problem is, deployment of > > > EJB fails with verifier errors (violation of sections 7.10.6, > > > 7.10.7 and 7.10.8, something about exceptions thrown by > > > implementation not being matched by declared by home/remote > > > interfaces). The very same EJB deploys fine without > > aspects. Any idea? > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[4]: [JBoss-dev] php5 is coming
I'd really prefer JSP integration or integration with some other popular Java based web scripting. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > julien viet > Sent: Sunday, March 30, 2003 3:57 PM > To: marc fleury > Subject: Re[4]: [JBoss-dev] php5 is coming > > > yes that's a good idea and I was thinking about it. Dain could > you send me details and contact infos ? > > A generic compiling service in jboss could be very usefull. > That + AOP could make wonders. > > julien > > mf> julien, > > mf> why don't you try to bring some of these guys in to do the > compiler for > mf> NUKES? JSP like writing for advanced programmatic modules? > > mf> marcf > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > >> Behalf Of Dain Sundstrom > >> Sent: Sunday, March 30, 2003 2:06 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: Re[2]: [JBoss-dev] php5 is coming > >> > >> > >> I talked with 2 compiler projects after JBoss boot camp and both were > >> interested in being integrated, but I dropped the ball and > >> got busy on > >> some other stuff. If anyone is interested in this I can send you the > >> contact info. > >> > >> -dain > >> > >> On Sunday, March 30, 2003, at 10:37 AM, julien viet wrote: > >> > >> > Hello Marcel, > >> > > >> > Sunday, March 30, 2003, 6:23:38 PM, you wrote: > >> > > >> > MA> julien viet wrote ([EMAIL PROTECTED]) > >> >>> JD> Though now that I think about it I would prefer that Java was > >> >>> more like > >> >>> JD> PHP in the sense of a light weight web application development > >> >>> language > >> >>> JD> with its rich extensions and apis. > >> >>> > >> >>> we discussed with Dain at boot camp and we wished > >> >>> having a way to dynamic compile a class, I mean with > >> >>> a java compiler written in java and taking class def from > >> >>> a classloader. > >> >>> > >> >>> That would enable a compilation service in jboss. Would > >> be great for > >> >>> nukes. Kopi compiler is written in 100% java and could be modified > >> >>> to achieve such results though I don't know about its license. > >> > > >> > MA> I did this for the PizzaCompiler as part of getting > >> Cocoon to work > >> > MA> without a JDK (only a JRE needed). For Pizza this is relatively > >> > MA> easy as it has pluggable resource-loaders (.class files are > >> > resources > >> > MA> to the compiler). The pizza compiler can be found at: > >> > > >> > cool, it could help for module or block scripting in Nukes, i.e get > >> > code class - fully generate class - compile it - generate xmbeam - > >> > deploy it > >> > > >> > pluggable resource loader is very helpfull, I don't know if we can > >> > have bytes of class through unified classloaders but that > >> would help. > >> > > >> > MA> http://pizzacompiler.sourceforge.net/ > >> > > >> > MA> I placed the sources for the pizza-loader and some wrapper and > >> > extension > >> > MA> classes needed to use it at: > >> > http://www.artefact.nl/pizza-loader.zip > >> > > >> > MA> I stripped of some extra's and commented out some lines > >> to keep it > >> > MA> simple and self hosting. > >> > > >> > MA> Hope this helps. > >> > > >> > MA> Regards, > >> > > >> > MA> Marcel Ammerlaan > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > julienmailto:[EMAIL PROTECTED] > >> > > >> > > >> > > >> > --- > >> > This SF.net email is sponsored by: > >> > The Definitive IT and Networking Event. Be There! > >> > NetWorld+Interop Las Vegas 2003 -- Register today! > >> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > >> > ___ > >> > Jboss-development mailing list > >> [EMAIL PROTECTED] > >> > https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > >> > >> --- > >> This SF.net email is sponsored by: > >> The Definitive IT and Networking Event. Be There! > >> NetWorld+Interop Las Vegas 2003 -- Register today! > >> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > >> ___ > >> Jboss-development mailing list [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > mf> --- > mf> This SF.net email is sponsored by: > mf> The Definitive IT and Networking Event. Be There! > mf> NetWorld+Interop Las Vegas 2003 -- Register today! > mf> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > mf> ___ > mf> Jboss-development mailing list > mf> [EMAIL PROTECTED] > mf> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > Best regards, > julienmailto:[EMAIL PROTECTED] > > > > --- > This SF.net email is sponsored by: >
RE: [JBoss-dev] hsqldb options
Sorry Peter, no offesne, but But could somebody explain what the hell he just posted? Sacha, pointed out McKoi. I'd like to see how good of a DB this is. Anybody have any experience with it? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Peter > Fagerlund > Sent: Sunday, March 30, 2003 6:29 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] hsqldb options > > > > söndagen den 30 mars 2003 kl 20.33 skrev marc fleury: > > > why don't we bring them on then? > > Send in another X number troops to fix the non result .. > > Pulezzze what is the non result U are experiencing ... the real or the > non-real ... and You say solve it with numbers -hehe ... > > You are such a non-general You are ... just a trooper ... U are ... > > Listen kids ... producing LOC is very un-interesting - Reducing LOC > with clear "spell" is productive ... Some of You are just adding > classes and LOC without keeping a entropy check ... for Your code -- > shining U are with LOC count. This is very much real here ... I like a > iteration of min 1k for a deploy/undeploy repeted test for thejbossteam > ploy deploy ... resulting in a non mem fatigue - then thejbossteam > might be considered to move on ... !!! > > check ... > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Strange, seems that you can turn of commit conflicts for dirty reads. This is actually READ_COMMITTED behavior. Cool. This DB seem cool. Wonder how well it works. > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 29, 2003 3:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Too many writes, to many Optimistic exceptions. > TRANSACTION_SERIALIZABLE usually is considered a performance > bottleneck in the same way that our QueuedPessismistic Entity > bean lock can be a bottleneck as well. I would like to try out > ECPERF with Mckoi to see what kind of performance boost we could get. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > > Labourey > > Sent: Saturday, March 29, 2003 1:09 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > Did you take a look at McKoi? http://www.mckoi.com/database/ > > > > >From the DOC: > > = > > There are four transaction isolation levels defined by the SQL standard. > > Each isolation level provides varying degrees of protection from seeing > > changes made by concurrent connections. The Mckoi database > engine supports > > the strongest isolation level defined by the standard - > > TRANSACTION_SERIALIZABLE. This isolation level prevents a > transaction from > > seeing all types of concurrent changes. The Mckoi database > engine achieves > > this through a multi-version data model that efficiently manages and > > isolates multiple views of the underlying data. > > > > During a transaction the connection sees a version (or snapshot) of the > > database that is isolated from any changes made by other connections. > > Additionally, any changes made within the context of a transaction are > > isolated from the rest of the database. This means that while a > > transaction > > is open the view a connection has of the database is blind from > > changes made > > by other concurrent connections. > > > > The multi-version data model allows the Mckoi database engine > to avoid all > > inter-transactional table/row locking and deadlock issues. No > > tables or rows > > are locked between concurrent transactions. While one transaction > > is reading > > from a table, another transaction may update the table at the > > same time. Any > > data consistency conflicts (for example, two connections > > committing a change > > that deletes the same row from a table) are detected when a > transaction is > > committed. > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Bill Burke > > > Sent: samedi, 29. mars 2003 19:00 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of David > > > > Jencks > > > > Sent: Saturday, March 29, 2003 10:55 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] hsqldb options > > > > > > > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > > > > > Currently we specify a tcp port and require a hsqldb mbean > > > to start the > > > > hsqldb server. This opens a port and requires explicit > > > hsqldb shutdown. > > > > > > > > Two other options that appear to work are: > > > > > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > > > This results in a > > > > totally in memory db, nothing saved to disk. IMO this is > > > appropriate for > > > > most of the testsuite since it eliminates problems with > > > data not being > > > > cleaned up between test runs. > > > > > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > > > This results > > > > in the db saved in a couple of files named like somefile. > > > No port is > > > > opened. No explicit shutdown of hsqldb seems to be > > > required (although I > > > > didn't test how much data is actually saved) > > > > > > > > Could someone who knows more about hsqldb please explain > > >
RE: [JBoss-dev] hsqldb options
Too many writes, to many Optimistic exceptions. TRANSACTION_SERIALIZABLE usually is considered a performance bottleneck in the same way that our QueuedPessismistic Entity bean lock can be a bottleneck as well. I would like to try out ECPERF with Mckoi to see what kind of performance boost we could get. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > Labourey > Sent: Saturday, March 29, 2003 1:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Did you take a look at McKoi? http://www.mckoi.com/database/ > > >From the DOC: > = > There are four transaction isolation levels defined by the SQL standard. > Each isolation level provides varying degrees of protection from seeing > changes made by concurrent connections. The Mckoi database engine supports > the strongest isolation level defined by the standard - > TRANSACTION_SERIALIZABLE. This isolation level prevents a transaction from > seeing all types of concurrent changes. The Mckoi database engine achieves > this through a multi-version data model that efficiently manages and > isolates multiple views of the underlying data. > > During a transaction the connection sees a version (or snapshot) of the > database that is isolated from any changes made by other connections. > Additionally, any changes made within the context of a transaction are > isolated from the rest of the database. This means that while a > transaction > is open the view a connection has of the database is blind from > changes made > by other concurrent connections. > > The multi-version data model allows the Mckoi database engine to avoid all > inter-transactional table/row locking and deadlock issues. No > tables or rows > are locked between concurrent transactions. While one transaction > is reading > from a table, another transaction may update the table at the > same time. Any > data consistency conflicts (for example, two connections > committing a change > that deletes the same row from a table) are detected when a transaction is > committed. > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Bill Burke > > Sent: samedi, 29. mars 2003 19:00 > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of David > > > Jencks > > > Sent: Saturday, March 29, 2003 10:55 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] hsqldb options > > > > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > > > Currently we specify a tcp port and require a hsqldb mbean > > to start the > > > hsqldb server. This opens a port and requires explicit > > hsqldb shutdown. > > > > > > Two other options that appear to work are: > > > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > > This results in a > > > totally in memory db, nothing saved to disk. IMO this is > > appropriate for > > > most of the testsuite since it eliminates problems with > > data not being > > > cleaned up between test runs. > > > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > > This results > > > in the db saved in a couple of files named like somefile. > > No port is > > > opened. No explicit shutdown of hsqldb seems to be > > required (although I > > > didn't test how much data is actually saved) > > > > > > Could someone who knows more about hsqldb please explain > > clearly why we > > > would want to continue using the setup we have now rather > > than one of the > > > tcp-port free options? > > > > > > > > > Man, if only hsqldb was transactional. We should recruit > > them to become a > > JBoss project and put keen transactional minds like David > > Jencks on the > > subject. A fully transactional in-memory DBMS would kick the > > crap out of > > everybody in benchmarking. I'm surprise Oracle 9iAS doesn't > > run in-process > > with the Oracle DBMS already > > > > Bill > > > > > > > > --- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register toda
RE: [JBoss-dev] hsqldb options
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Saturday, March 29, 2003 10:55 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] hsqldb options > > > Prompted by a customer, I did some experiments with hsqldb options. > > Currently we specify a tcp port and require a hsqldb mbean to start the > hsqldb server. This opens a port and requires explicit hsqldb shutdown. > > Two other options that appear to work are: > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a > totally in memory db, nothing saved to disk. IMO this is appropriate for > most of the testsuite since it eliminates problems with data not being > cleaned up between test runs. > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > This results > in the db saved in a couple of files named like somefile. No port is > opened. No explicit shutdown of hsqldb seems to be required (although I > didn't test how much data is actually saved) > > Could someone who knows more about hsqldb please explain clearly why we > would want to continue using the setup we have now rather than one of the > tcp-port free options? > Man, if only hsqldb was transactional. We should recruit them to become a JBoss project and put keen transactional minds like David Jencks on the subject. A fully transactional in-memory DBMS would kick the crap out of everybody in benchmarking. I'm surprise Oracle 9iAS doesn't run in-process with the Oracle DBMS already Bill --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
