[DBCP] Managed Connection support
I just posted a patch JIRA which adds support for container managed connections to DBCP. In an environment where you have an accessible transaction manger such as Tomcat (when installed), Geronimo or OpenEJB, this patch allows adds support for pooling managed connections to an XA or non-XA data base. There are many libraries that use DBCP for non-managed environments, but when additional resources such as a JMS provider are added to the mix, they have to replace DBCP with something else. If you search google for XA and DBCP, you will loads of painful direction on how to replace DBCP with something else. I personally want to use DBCP in Tomcat with ActiveMQ. Anyways, enough with motivation To use the new code, you need access to a TranactionManager (this code just creates a new Geronimo one). transactionManager = new TransactionManagerImpl(); Then you either create an XADataSource and DataSourceXAConectionFactory or as this code does, create a normal DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory Properties properties = new Properties(); properties.setProperty(user, username); properties.setProperty(password, password); ConnectionFactory connectionFactory = new DriverConnectionFactory( new TesterDriver(), jdbc:apache:commons:testdriver, properties); // wrap it with a LocalXAConnectionFactory XAConnectionFactory xaConnectionFactory = new LocalXAConnectionFactory( transactionManager, connectionFactory); Now you create a pool as normal (full reuse here). pool = new GenericObjectPool(); pool.setMaxActive(getMaxActive()); pool.setMaxWait(getMaxWait()); // create the pool object factory PoolableConnectionFactory factory = new PoolableConnectionFactory( xaConnectionFactory, pool, null, SELECT DUMMY FROM DUAL, true, true); pool.setFactory(factory); Finally, you create a special ManagedDataSource using the pool above and the special TransactionRegistry object obtained from the XAConnectionFactory. ds = new ManagedDataSource(pool, xaConnectionFactory.getTransactionRegistry()); ds.setAccessToUnderlyingConnectionAllowed(true); That's it. The data source and connections work as normal until you start a transaction using the TransactionManager. When you use a connection while the transaction is active, the connection is enlisted in the transaction. When the transaction is complete, the connection is committed (or rolledback) and the connection returns to normal. Most of the new code extends existing classes or uses existing classes without modification. The key to this reuse is the TransactionRegistry abstraction which maintains a map from the Connection to the XAResource for that connection. The XAResource is needed to enlist a connection in a transaction. The TransactionRegistry and associated TransationContext class encapsulate all interactions with the TransactionManager leaving the Connection implementation relatively simple (making reuse easier). For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload: Streaming mode
Excellent thanks, -dain On Nov 4, 2006, at 1:23 AM, Henri Yandell wrote: Done: http://people.apache.org/repo/m1-snapshot-repository/commons- fileupload/jars/ Hen On 11/2/06, Dain Sundstrom [EMAIL PROTECTED] wrote: In the mean time, can you publish a SNAPSHOT? Also, is anyone looking at releasing this stuff? Am I on the wrong mailing list (I couldn't find one for commons-fileupload)? Thanks, -dain On Nov 2, 2006, at 12:38 AM, Henri Yandell wrote: Our (Commons) nightly build machine (vmbuild.apache.org) was on a vmware zone that hasn't come back after the machine migration. It took care of both the nightly dist build and the m1 snapshot repo deployments. I'll pester for info again on it tomorrow; last I heard was that we don't have vmware expertise and so it's a case of finding nudging those who were involved with infra back when it was down to look into it. It's all in SVN, so if nothing's forthcoming I'll look into setting something up (unless someone else volunteers - always appreciated :) ). Sad that we pestered Craig to get it off of his workstation, and we've not managed to achieve his quality of service. Hen On 10/29/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Has this code been Released yet? The latest version I see is 1.1.1 and it doesn't seem to contain the FileItemIterator class. Also there don't seem to be any nightly snapshots available. In the mean time I can build this by hand, but I'd prefer a Release or SNAPSHOT in a maven repo. Thanks for any help, -dain On May 23, 2006, at 5:10 PM, Dain Sundstrom wrote: Wow. I can't wait to get my hands on this code. -dain On May 23, 2006, at 4:24 AM, Yoav Shapira wrote: Hola, +1 to you getting commons-fileupload karma and doing it yourself ;) Yoav On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have developed a modified version of the commons-fileupload, which allow a true streaming mode. In other words, there's no need for internal byte arrays or temporary disk files, you simply iterate through the items, get an InputStream on the items, read and process the InputStream (for example, run an XML parser on it) and that's it. The API remains unchanged and the modifications are strictly internally. For obvious reasons, the patches are non-trivial. So far I have splitted some changes into three patches, which I have posted in Jira issues. However, to get this patches in, one after the other, I see as my only chances, if an existing developer would express interest on the changes, review and guide my work and accept patches step by step. Is there anyone who volunteers doing the job? Perhaps, being an active ws committer, I might after some time as well receive Karma for commons-fileupload and finish the work, if I have earned some trust. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: general- [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: general- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload: Streaming mode
In the mean time, can you publish a SNAPSHOT? Also, is anyone looking at releasing this stuff? Am I on the wrong mailing list (I couldn't find one for commons-fileupload)? Thanks, -dain On Nov 2, 2006, at 12:38 AM, Henri Yandell wrote: Our (Commons) nightly build machine (vmbuild.apache.org) was on a vmware zone that hasn't come back after the machine migration. It took care of both the nightly dist build and the m1 snapshot repo deployments. I'll pester for info again on it tomorrow; last I heard was that we don't have vmware expertise and so it's a case of finding nudging those who were involved with infra back when it was down to look into it. It's all in SVN, so if nothing's forthcoming I'll look into setting something up (unless someone else volunteers - always appreciated :) ). Sad that we pestered Craig to get it off of his workstation, and we've not managed to achieve his quality of service. Hen On 10/29/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Has this code been Released yet? The latest version I see is 1.1.1 and it doesn't seem to contain the FileItemIterator class. Also there don't seem to be any nightly snapshots available. In the mean time I can build this by hand, but I'd prefer a Release or SNAPSHOT in a maven repo. Thanks for any help, -dain On May 23, 2006, at 5:10 PM, Dain Sundstrom wrote: Wow. I can't wait to get my hands on this code. -dain On May 23, 2006, at 4:24 AM, Yoav Shapira wrote: Hola, +1 to you getting commons-fileupload karma and doing it yourself ;) Yoav On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have developed a modified version of the commons-fileupload, which allow a true streaming mode. In other words, there's no need for internal byte arrays or temporary disk files, you simply iterate through the items, get an InputStream on the items, read and process the InputStream (for example, run an XML parser on it) and that's it. The API remains unchanged and the modifications are strictly internally. For obvious reasons, the patches are non-trivial. So far I have splitted some changes into three patches, which I have posted in Jira issues. However, to get this patches in, one after the other, I see as my only chances, if an existing developer would express interest on the changes, review and guide my work and accept patches step by step. Is there anyone who volunteers doing the job? Perhaps, being an active ws committer, I might after some time as well receive Karma for commons-fileupload and finish the work, if I have earned some trust. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload: Streaming mode
Has this code been Released yet? The latest version I see is 1.1.1 and it doesn't seem to contain the FileItemIterator class. Also there don't seem to be any nightly snapshots available. In the mean time I can build this by hand, but I'd prefer a Release or SNAPSHOT in a maven repo. Thanks for any help, -dain On May 23, 2006, at 5:10 PM, Dain Sundstrom wrote: Wow. I can't wait to get my hands on this code. -dain On May 23, 2006, at 4:24 AM, Yoav Shapira wrote: Hola, +1 to you getting commons-fileupload karma and doing it yourself ;) Yoav On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have developed a modified version of the commons-fileupload, which allow a true streaming mode. In other words, there's no need for internal byte arrays or temporary disk files, you simply iterate through the items, get an InputStream on the items, read and process the InputStream (for example, run an XML parser on it) and that's it. The API remains unchanged and the modifications are strictly internally. For obvious reasons, the patches are non-trivial. So far I have splitted some changes into three patches, which I have posted in Jira issues. However, to get this patches in, one after the other, I see as my only chances, if an existing developer would express interest on the changes, review and guide my work and accept patches step by step. Is there anyone who volunteers doing the job? Perhaps, being an active ws committer, I might after some time as well receive Karma for commons-fileupload and finish the work, if I have earned some trust. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: offtopic - Woodcrest vs. Xeon
IIRC the single core xeons are the old architecture, and really suck (speed, heat and cost) compared to the new core architecture. -dain On Oct 23, 2006, at 12:57 PM, Will Glass-Husain wrote: Thanks, Geir, Yes, I'm comparing two Woodcrest chips (4 cores total) with 2 single-core Xeon chips. I'll check the specs again -- good comments. Someone recommended this Wiki article, I really liked it. http://en.wikipedia.org/wiki/Intel_Xeon That's pretty cool about the benchmark. WILL On 10/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Full disclosure, I work for Intel. :) First, are you sure it's a 2GHz Woodcrest? I thought it would be a 3GHz part. Second, is it two Woodcrest (for 4 cores total) or just 1 Woodcrest? Third, woodcrest is an internal code name, and the parts are sold under the Xeon brand, so which Xeon is a question you want to ask the vendor - it could be woodcrest based as well. Finally, the current world record in spec's JBB2005 benchmark is held by IBM with their JVM on woodcrest (Xeon 5160) at 114k bops/JVM on a 4 core machine... You can go see the results here : http://www.spec.org/jbb2005/results geir Will Glass-Husain wrote: Hi, This is a little off-topic but I thought I'd do a quick poll. I've got an opportunity to reconfigure my multi-server Tomcat/Java setup for a computation-heavy webapp. One vendor is proposing dual process Woodcrest (dual core) 2.0 GHz, the other is promoting dual Xeon 3.2GHz. The Woodcrest's have slower clock speeds but the dual core is supposed to make it faster. Just curious if anyone has experience with the Woodcrest servers - in particular if anyone has benchmarked Sun's JDK on the two processors with a computation heavy app I'd love to hear from them. (Can Sun's JDK make effective use of the multi-processor, multi-core system?) Cheers, WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload: Streaming mode
Wow. I can't wait to get my hands on this code. -dain On May 23, 2006, at 4:24 AM, Yoav Shapira wrote: Hola, +1 to you getting commons-fileupload karma and doing it yourself ;) Yoav On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have developed a modified version of the commons-fileupload, which allow a true streaming mode. In other words, there's no need for internal byte arrays or temporary disk files, you simply iterate through the items, get an InputStream on the items, read and process the InputStream (for example, run an XML parser on it) and that's it. The API remains unchanged and the modifications are strictly internally. For obvious reasons, the patches are non-trivial. So far I have splitted some changes into three patches, which I have posted in Jira issues. However, to get this patches in, one after the other, I see as my only chances, if an existing developer would express interest on the changes, review and guide my work and accept patches step by step. Is there anyone who volunteers doing the job? Perhaps, being an active ws committer, I might after some time as well receive Karma for commons-fileupload and finish the work, if I have earned some trust. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing interim dated builds from /www/www.apache.org/dist/java-repository
On Jan 7, 2005, at 6:56 AM, Mark R. Diggory wrote: Dain Sundstrom wrote: I would hope so. These projects have a trivial or non existent set of dependencies. Take a look at a big project using maven and you will see that they use lots of repos, because ibiblio tends not to have everything necessary or was down when someone was working. Yet, ibiblio is an exact mirror of dist/java-repository without deletion. There is nothing in dist/java-repository that is not also present on ibibilio and the rsync is every four hours so there is actually only a tiny lag concerning differences. Ibiblio is the canonical repository of Maven, you would have to be doing a tremendous about of overriding to change its location on a consistent basis. Why? waist such time. Regardless of what people should and shouldn't do, they do this all the time. My understanding is that Ibibilio is a system dedicated to mirroring massive amounts of content with raid/fallover and multiple gateways/ISP's, I would expect its up time to be far more consistent than even that of Apache. :) I would expect that also, but it simply isn't true. Ibiblio has blackouts and brownouts all the time. The latter are much worse as it doesn't immediately return an error code; instead, it spends like 5 minutes downloading a 20k jar. In Maven, the repository used to get downloads from is not a project attiribute, it is a user decision/configuaration of the client. So really, a project that ends up with any dependency downloads directly from dist/java-repository is not the best solution, ibiblio is the more persistent and canonical point to be downloading from at this point. Take a look at geronimo and you will see that it is impractical for a user to hunt down dependencies. The code from a source distribution should just build, which means that all the dependencies *must* always be available. A simple search of the files in the filesystem for any string matches to dist/java-repository would suffice. I checked it out and searched it on my laptop just now using Eclipse, there are no references in any of the files in any of geronimo. I been doing greps on cvs.apache.org and find the following cases as examples of references jakarta-turbine-2/project.properties,v:maven.repo.remote=http:// www.ibiblio.org/maven/,http://www.apache.org/dist/java-repository/ This is a bad usage of java-repository, but not a show stopper, It will go to ibilio first then the ASF Repository, things should work fine as long as ibibilio's up. We should make sure there are no cases of the following for example: jakarta-turbine-2/project.properties,v:maven.repo.remote=http:// www.apache.org/dist/java-repository/ Thats bad, theres really no reason this should be done at this point and time. Heres a really good example of a reference we promote usage of: jakarta-commons/chain/project.properties,v: maven.repo.central.directory=/www/www.apache.org/dist/java-repository maven.repo.central.directory is property which states where to publish to, not where to download from. This is exactly my point. If someone pulled down that source, it potentially won't build. Once you start messing with repos, it can eliminate the possibility of recreating *historical* builds. It might be good to go through the Apache projects that are in java-repository and see if any are packaged to download dependencies from there, I doubt it that here would be any occurances however. As a majority of the files were originally published to/against ibiblio in the first place. Unfortunately, not all projects that use the apache repos are not hosted at apache. We've never publicized the the java-repository to be used externally. It 's content was originally migrated from Apache by Jason Van Zyl and Myself with the goal of getting publishing of Apache content back to Apache (with Ibibilio as a mirror). Anyone using it would be using it at their own risk. I believe that any consultation with the ASF Repository project here at Apache would have made this issue clear to them. Further, my point is that currently there shouldn't be projects dependent on java-repository as its location for resolving jar dependencies, there is an entire discussion on the [EMAIL PROTECTED] list concerning this subject, the repository used is a configuration of the client right now (in Maven) not a characteristic of the project.xml of a maven project. You can suggest a repository to use in properties handed to Maven, but the default is always www.ibiblio.org/maven. Our initial creation of java-repository was never not to have a Standalone Maven repository at Apache, but to provide a simple means for Apache developers to publish release jars and distributions to Ibibilio until such a time when distributed repositories become a greater practice. Its a real bad idea to force build dependencies against it at this time until we get it stabilized. Its entire contents
Re: [OT] Which Linux distribution for Java development?
One thing you *may* care about is using certified Java VM. Sun requires that a VM be certified on an exact distribution, so if you use a VM certified for Red Hat on say Mandrake, you are using a non-certified installation. I know this sound incredibly lame, but it is very important for projects like Geronimo where we are working on certifying our code, since Sun only allows a library to be certified on a certified VM. FWIU, the only linux distros with certified VMs are Red Hat (enterprise?) and Suse. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Jan 6, 2005, at 1:00 PM, robert burrell donkin wrote: i'd say now that provided you go for an up-to-date distribution, you shouldn't notice much difference between most distro's when it comes to java (so you probably want to choose on some other basis). the biggest choice is how you install your java: the traditional way (stuff everything somewhere odd in /opt or /var outside the standard linux directory structure) or use a packaging system such as http://www.jpackage.org/ (which is now pretty good). i've used mandrake as a secondary java development environment for a number of years and have no complaints. i've done some work on a fedora box recently and been very impressed (i used to hate red hat). debian is very good for servers but less so for java development using a GUI. it has a well deserved reputation for being tough for newbies but is very powerful. (i installed my last server with debian and haven't had a single regret.) - robert On 6 Jan 2005, at 20:05, Alain Gaeremynck wrote: Mandrake is the most User centric desktop distro that i know of. It is base on the red hat core and it has a control panel application to manage the configuration of the different componant. Since i was fortunate enough to get a lot of help when i first switched from windows to Linux i am more then happy to return the favor so if you have any specific question related to linux don't hesitate to contact me off the list so has not to clutter it with non jakarta related chatter Dennis Lundberg wrote: I'm considering moving to a Linux environment for my Java development. Which distros would be a good choice and which should one stay away from? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alain Gaeremynck CTO Le Groupe Interstructure (514) 374-1110 (514) 825-7810 cell weblog: http://www.sanssucre.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing interim dated builds from /www/www.apache.org/dist/java-repository
On Jan 4, 2005, at 8:34 PM, Mark R. Diggory wrote: Please excuse the cross post. I'm planning to run some commands on the java-repository to remove interim builds and SNAPSHOTS. Specifically, I'll be running: If you remove SNAPSHOTS, it not only can it break head branches of projects, it can break milestone source releases that people are still using. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Support provider
Are you going to tame down your website also? -dain On Dec 1, 2004, at 5:55 PM, Mark Brewer wrote: OK. Clearly we would tame it down if you'd like. That's our marketing blurb from our website. Let us know. Thanks - Mark -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 5:50 PM To: Jakarta General List Cc: Mark Brewer; [EMAIL PROTECTED] Subject: RE: Jakarta Support provider I don't know how much vetting we do, but despite the fact that this is a vendor page, I believe that a lot of people would complain about the phrase [Covalent is] the only source of full commercial support for Apache Tomcat. Now that the ASF has established the PRC, perhaps it is time we turned control over such vendor pages to the PRC to make sure that a message consistent with the ASF's neutrality is preserved. --- Noel -Original Message- From: Mark Brewer [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 19:48 To: [EMAIL PROTECTED] Subject: Jakarta Support provider To whom it concerns, Covalent Technologies would like to be added to Developer Support section of this page on the Jakarta site: http://jakarta.apache.org/site/vendors.html Below is the info you've requested. Website: www.covalent.net http://www.covalent.net Description: Covalent is the leader in products and services for Apache Tomcat, the world's leading Web server, and the only source of full commercial support for Apache Tomcat. Covalent has assembled the deepest talent pool of Apache experts in the industry. Through Covalent's products and services, Apache/Tomcat users receive all the flexibility and benefits of open source, with the support and reliability of a commercial enterprise fully dedicated to those open source technologies. Location: Worldwide Contact: [EMAIL PROTECTED] Let us know if there is anything further you require. Thanks, Mark Brewer 925.974.8800 x5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
On Oct 27, 2004, at 4:15 PM, Bernhard Fastenrath wrote: method pointers? closures? Is anybody going to suggest self-modifying java assembler code as a language feature? I don't really see how you got from method pointers and closures to self-modifying code (I see that as a bit of fear mongering). Is the goal to break Java and render it useless? In my opinion we can live without closures. You didn't have to attach for a bit longer. I actually love closures, and think it would be a great addition to Java. I spend a lot of time tracking down poorly written try/finally blocks in people's code where they don't properly close DB connections, IO streams, Jar files, and even delete their temp files. A good closure library would virtually eliminate this type of programming errors. Now I still doubt Sun's ability to pull of this feature after seeing the junk in 1.5, but if I got to choose only one major language feature to add it would be closures. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features - performance and stability
+10 -dain On Oct 28, 2004, at 1:24 AM, Danny Angus wrote: This is a bit of a rant, I know but... One thing I would like to see Sun do, from the point of view of my previous role at work, would be to devote more effort to improving the stability and performance of the Hotspot VM on all platforms. From what I can see are a number of defects in the Hotspot VM that seriously affect the capapacity of many server products to achieve high uptimes and high throughputs. Is this experience borne out by anyone else here? Could we see some clarification of the garbage collection and optimisation mechanisms? It seems to me that there are a very large number of poorly documented options for garbage collection and optimisations which are neither specification features nor implementation features, but are in wide use by many people who are struggling to maintain high levels of service in the real world in the face of defects and failure of the JVM to behave as documented. One example is the permanent generation size, Sun tell us that allocations in the permanent generation will continue up to the maximum size of the permanent space, at which point further allocations will be from the tenured heap space. Seems sensible so far. However it appears that requests for permanent allocation trigger a full garbage collection when they cannot be satisfied in the permanent generation, this leads to the JVM thrashing and effectively defeats the notion that tenured space could be used as an overflow. The fact that this was not documented is almost as serious because it removes some of the imperative which might otherwise encourage us to profile not only hepa usage but also permanent generation requirements. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. *** *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features - performance and stability
On Oct 29, 2004, at 8:43 AM, Danny Angus wrote: On Fri, 29 Oct 2004 08:11:03 -0700, Dain Sundstrom [EMAIL PROTECTED] wrote: +10 I make that 10 trillion. Did I hit a nerve there Dain? ! Yes! One thing that has been bugging me for years it the URLClassLoader on windows, locks the jars it loads, and the only way to release the lock is to reboot the vm. It would be nice to have some way to release the lock. Also we have been running into problems with NIO since it came out. It is incredibly unstable and you endup tweaking code for each platform. Oh and the new GC bugs in 1.5 are totally annoying. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
On Oct 27, 2004, at 1:10 AM, Danny Angus wrote: Dain wrote: If you want method pointers today, just get a good byte code generation tool. Yeah I know, and I seriously believe that workarounds such as this do more to harm the so-called purity of Java than providing explicit language level mechanisms for method pointers. I understand what you are saying, but do you believe that Sun could actually get such a feature right? My guess is they would slap so many coding restrictions and security checks around this feature to make is most useless. So, yes, I am arguing that no feature is better than a poorly implemented feature. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
On Oct 26, 2004, at 1:17 AM, Danny Angus wrote: 1/ Ok don't flame me... Method pointers If you want method pointers today, just get a good byte code generation tool. We use cglib in Geronimo to generate FastMethod objects, which look a lot like reflection Method but are about a 100 times faster (there only slightly slower than an invoke virtual). -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features: Class Instance Variables (a la Smalltalk)
Can you explain what this is and why it is more useful then annoying? IMHO, most of the new features in Java 5 are way more annoying then useful. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Oct 25, 2004, at 2:42 PM, Gary Gregory wrote: Future JDK features: Class Instance Variables (a la Smalltalk). Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 27, 2004, at 4:20 PM, Oliver Zeigermann wrote: I know I keep repeating myself all the time, but for the special case of Hibernate doesn't this http://www.hibernate.org/196.html From the link above: Using Hibernate (by importing Hibernate's public interfaces in your Java code), and extending Hibernate (by subclassing or implemention of an extension interface) is considered by the authors of Hibernate to be dynamic linking. Hence our interpretation of the LGPL is that the use of the unmodified Hibernate source does not affect the license of your application code. What if the authors change there mind? Until this opinion is expressed in the legal license, it means nothing. As an independent contractor I learned the hard way that you get everything in the legal contract. Also Hibernate is controlled by JBoss and we all know how happy they are to bring in the lawyers. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
Larry, I'm surprised that no one answered this (at least that I saw). From what I understand, ASF believes that those on PMC have liability protection from the ASF because the PMC members are acting on behalf of the organization. Further is it seems that the ASF does not believe this protection extends to those not in the PMC (this is my personal logical conclusion based on statements around why someone would like to join a PMC). This protection is usually referenced when people talk about IP, and I'm not sure if it extends to other areas. I'm not aware of an official statement on this, but it would be nice to have one. Happy Holidays -dain /* * Dain Sundstrom * Partner * Core Developers Network */ On Dec 21, 2003, at 9:08 PM, Lawrence E. Rosen wrote: No, that is not correct. The point of having most committers on the PMC is not to keep discussions out of google. The point of getting them on the PMC is so that the ASF can legally protect them, and so that they are legally empowered to participate in the decisions that govern the project. Would someone please explain what protection committers expect from ASF? And what legal empowerment is being granted? /Larry Rosen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 5:58 PM, Geir Magnusson Jr. wrote: On Dec 22, 2003, at 6:23 PM, Dain Sundstrom wrote: Larry, I'm surprised that no one answered this (at least that I saw). From what I understand, ASF believes that those on PMC have liability protection from the ASF because the PMC members are acting on behalf of the organization. Further is it seems that the ASF does not believe this protection extends to those not in the PMC (this is my personal logical conclusion based on statements around why someone would like to join a PMC). This protection is usually referenced when people talk about IP, and I'm not sure if it extends to other areas. I'm not aware of an official statement on this, but it would be nice to have one. I did respond. As I understand it, here is no protection for PMC members except for the chair, if he or she was acting on behalf of the corporation in good faith. Sorry missed your reply. From what I have seen there are vastly differing opinions on this matter (from ranking people in ASF). Anyway, it would be nice to see something official on this matter, but it is a legal matter and therefore unlikely to happen (at least anytime soon ;) And if you don't know Larry, he's a well-known attorney specializing in OSS matters. I know Larry. He used to a company I used to do business with. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 6:13 PM, Geir Magnusson Jr. wrote: On Dec 22, 2003, at 7:07 PM, Dain Sundstrom wrote: On Dec 22, 2003, at 5:58 PM, Geir Magnusson Jr. wrote: On Dec 22, 2003, at 6:23 PM, Dain Sundstrom wrote: Larry, I'm surprised that no one answered this (at least that I saw). From what I understand, ASF believes that those on PMC have liability protection from the ASF because the PMC members are acting on behalf of the organization. Further is it seems that the ASF does not believe this protection extends to those not in the PMC (this is my personal logical conclusion based on statements around why someone would like to join a PMC). This protection is usually referenced when people talk about IP, and I'm not sure if it extends to other areas. I'm not aware of an official statement on this, but it would be nice to have one. I did respond. As I understand it, here is no protection for PMC members except for the chair, if he or she was acting on behalf of the corporation in good faith. Sorry missed your reply. From what I have seen there are vastly differing opinions on this matter (from ranking people in ASF). Anyway, it would be nice to see something official on this matter, but it is a legal matter and therefore unlikely to happen (at least anytime soon ;) Feel free to send them to me. I'm interested. I'll be happy to report back a summary or correction. I doubt the ASF wants me to make declarations about what legal protections they provide to PMC members. Even if they did want me to come up with a straw man, I wouldn't even know where to start. And if you don't know Larry, he's a well-known attorney specializing in OSS matters. I know Larry. He used to a company I used to do business with. Ah Sorry. :) AHHH... can't type today. Meant to write He use to *represent* a company... -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publicizing ApacheCon 2003
Is there a more specific location other than Vegas? -dain On Thursday, September 4, 2003, at 11:13 AM, Ceki Gülcü wrote: If I am not mistakem, early-bird registration seems to be already over... Anyway, I added a link at the top of the jakarta sidebar menu. I am confident people will find things to improve but you've got to start somewhere. This is CVS. We can revert if need be. At 07:41 AM 9/4/2003 -0500, Glenn Nielsen wrote: +1 But wait until the sessions are available at www.apachecon.com Ceki Gülcü wrote: Hello everyone, Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19 November 2003. For this event to be the success that it deserves to have, we need to make an effort to publicize it as much as possible. I have created a series of icons that one can use to link to http://www.ApacheCon.com. The icons are available at http://www.apache.org/~ceki/ac2003/ We should at least add a salient image on the sidebar of the jakarta pages. Comments? -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp See you in November at ApacheCon US 2003 in Las Vegas. http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /* * Dain Sundstrom * Partner * Core Developers Network */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
