proxool-developer — Developer's discussion list

RE: [Proxool-developer] [Fwd: DataSource and JDK 1.2]

[Martin C. <mar...@de...>]

> Yep, go ahead. I will either release 0.8.3 or 0.9.0 next depending on
Hibernate's requirements.  Cglib 2 > is still in beta at the moment anyway.

I've just woken up from a long coma... or perhaps maybe a hibernation
(insert sick laughter here)... Can someone elaborate what are the
requirements for Hibernate and issues with cglib?

Martin

Re: [Proxool-developer] [Fwd: DataSource and JDK 1.2]

[Bill H. <bi...@lo...>]

Hi Christian,

> > I'm wrapping up the DataSource support :)

:) :) :) Well done with that Christian.

> > JDK 1.2 users will not be able to compile Proxool without having the
> > JNDI jar present in their classpath. Unlike the JMX and JDBC
> > extentions the JNDI jar is not redistributable. This means that 1.2
> > users will have to make the effort of downloading the jar from Sun to
> > compile.

That's acceptable. (Unavoidable anyway). Perhaps we could make the Ant
task provide a message along those lines.

> > We need to document this somewhere. In fact, would it not be a good
> > idea to have a top level "dependencies" page in our docs?

Sounds good. We have a short paragraph at the bottom of the download
page that needs to be expanded. Especially with regards to what is
needed when you start to use different features (JNDI, JAXP, etc.)

> > What is the status of the cglib/hibernate versioning saga? Is it ok
> > for me to check in the DataSource stuff now if it comes with a
> > working test suite? 

Yep, go ahead. I will either release 0.8.3 or 0.9.0 next depending on
Hibernate's requirements.  Cglib 2 is still in beta at the moment
anyway.

I think we were going to look into supporting Cglib 1 and 2 at the same
time weren't we? And maybe leave the Enhancer er... enhancement until a
little later. (Info: we need to make some changes to Proxool to support
Cglib 2. Also, there is a performance improvement - Enhancer - available
in Cglib 2, but we probably won't use that immediately to keep backwards
compatibility). I'll take a look at how we might do that.

Bill Horsman

[Proxool-developer] [Fwd: DataSource and JDK 1.2]

[Bill H. <bi...@lo...>]

-----Forwarded Message-----
> From: Christian Nedregaard <chr...@em...>
> Subject: DataSource and JDK 1.2
> Date: Sun, 07 Dec 2003 14:56:53 +0100

> I'm wrapping up the DataSource support :)
> 
> JDK 1.3+ have JNDI included so there's no additional dependecies
> there.
> 
> However, JDK 1.2 does not come bundled with JNDI. Users will not have
> a problem running a binary Proxool distribution as the JNDI
> entrypoint will be through reflection (as we did with JMX). 
> 
> JDK 1.2 users will not be able to compile Proxool without having the
> JNDI jar present in their classpath. Unlike the JMX and JDBC
> extentions the JNDI jar is not redistributable. This means that 1.2
> users will have to make the effort of downloading the jar from Sun to
> compile.
> 
> We need to document this somewhere. In fact, would it not be a good
> idea to have a top level "dependencies" page in our docs?
> Here we could explain that cglib is the only mandatory dependency
> (which is pretty cool), and then go on to explain what type of usage
> would add other dependencies.
> 
> By the way: 
> What is the status of the cglib/hibernate versioning saga? Is it ok
> for me to check in the DataSource stuff now if it comes with a
> working test suite? 
> 
> CHR

[Proxool-developer] Forum Entry: Shutting down Proxool

[Bill H. <bi...@lo...>]

By: zyzgy ( Jason Oh ) 
shutting down proxool   
2003-11-20 15:31 
hello,
i have a trivial question. just started using proxool and am not sure
about how to shutdown the proxool connection pool. i can close all the
connections manually (conn.close()), but don't know if it is up to me to
shutdown the proxool pool. i've noticed that there is a shutdown hook
which starts when the application exits--does this take care of
connection pool cleanup at application exit?

thanks for your help! 


        By: billhorsman ( Bill Horsman ) 
        RE: shutting down proxool   
        2003-11-20 15:41 
        Hi Jason,
        
        It depends in what environment you are running Proxool... if
        it's an application running in it's own JVM and you're using JDK
        1.3 or later then the ShutdownHooks will do exactly what you
        want. 
        
        JDK 1.2 doesn't support ShutdownHooks, in which case you should
        call ProxoolFacade.shutdown() explicitly.
        
        If you are running Proxool in something like a servlet container
        (e.g. JBoss, Resin) then you need to explicitly shutdown too -
        otherwise if you redeploy you end up with two instances of
        Proxool (the JVM doesn't call the shutdown hooks on a redeploy).
        In that case, you also need to call shutdown() explicitly.
        Normally in a servlet's destroy() method. Alternatively, use the
        ServletConfigurator and it will do it for you.
        
        Just to make sure you are using the pool correctly: you call
        conn.close() after every database action right? You shouldn't
        leave them open until the application is shutting down - that is
        what Proxool does for you.
        
        Cheers,
        Bill Horsman 
        
        
        By: zyzgy ( Jason Oh ) 
        RE: shutting down proxool   
        2003-11-20 16:03 
        hi bill,
        thanks for your prompt response! yes, i'm currently running
        jdk1.4.2 in a testing environment (command-line) and will have
        to migrate everything to a servlet container soon (tomcat4). i
        call conn.close() immediately after every db call currently.
        
        so, in the context of a servlet container, you mention that
        shutdown() must be called explicitly. i use the DriverManager to
        getConnection() and use the proxool PropertyConfigurator to
        initialize proxool. on which object must i invoke shutdown()
        once i move to tomcat?
        
        also, i'm thinking that i will have to use transactions as part
        of my app. do you have any suggestions/ideas with respect to the
        best way to use transactions in concert with proxool?
        
        thanks again for your help,
        jason 
        
        
        By: billhorsman ( Bill Horsman ) 
        RE: shutting down proxool   
        2003-11-20 16:32 
        Hi Jason,
        
        Take a look here:
        http://proxool.sourceforge.net/servlets.html
        
        It tells you how to use the ServletConfigurator to automatically
        configure Proxool using a properties file. The benefits of which
        are:
        
        1) No Proxool code in your app, just some lines in web.xml
        
        2) ServletConfigurator will automatically call
        ProxoolFacade.shutdown() in its destroy() method.
        
        In answer to your specific question about calling shutdown().
        You use ProxoolFacade.shutdown(). It's a static method, so no
        object needed.
        
        As far as transactions go, Proxool treats them transparently.
        That is, you use them exactly as you would with no connection
        pool: open the connection at the start of the transaction, close
        the connection at the end of the transaction.
        
        Cheers,
        Bill
        
---
This forum entry is being posted on this list because the old forum is
being deleted.

Re: [Proxool-developer] On the fly configuration

[Christian N. <chr...@em...>]

If you are running in an appserver with a JMX (http://java.sun.com/products/JavaManagement/) console (eg. JBoss) you can make a Proxool pool runtime configurable simply by setting the jmx property to "true".

As of now the changes will not be persisted across server restarts.

Bill:
having a Log4J watcher like functionality seems like a good idea.

CHR


----- Original Message -----
From: "Kiran T" <mah...@ho...>
Date: Wed, 19 Nov 2003 15:48:21 +0000
To: pro...@li...
Subject: Re: [Proxool-developer] On the fly configuration

> Is it possible to change the Proxool connection and pool configuration
> properties without restarting the application server?
> 
> >Yes it is. Look at ProxoolFacade.updateConnectionPool(), and
> >redefineConnectionPool().
> 
> ...But I still have to restart my jvm to read the updated XML or property 
> files. I typically want to increase or decrease the number of connections 
> depending on the traffic. Can I do it without restarting the server( jvm) ?
> 
> _________________________________________________________________
> From the hottest toys to tips on keeping fit this winter, you’ll find a 
> range of helpful holiday info here.  
> http://special.msn.com/network/happyholidays.armx
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

-- 
__________________________________________________________
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Search Smarter - get the new eXact Search Bar for free!
http://www.exactsearchbar.com/

Re: [Proxool-developer] On the fly configuration

[Bill H. <bi...@lo...>]

Hi Kiran,

On Wed, 2003-11-19 at 16:48, Kiran T wrote:

> ...But I still have to restart my jvm to read the updated XML or property 
> files. 

0.10 will include that functionality I would think. That is, reloading
XML configuration files at runtime. Or something similar that would have
the same effect. 

In the meantime, you can do it programmatically if you want. For
instance:

  Properties properties = new Properties();
  properties.setProperty("proxool.maximum-connection-count", "20");
  ProxoolFacade.updateConnectionPool("alias", properties);

I admit that's not very elegant compared to the simplicity of updating
an XML file. The focus of 0.10 will be exactly this sort of thing.

What do you people think to Log4J like behaviour where you can configure
Proxool to "watch" an XML file and reload it if it changes?

Regards,

Bill Horsman

Re: [Proxool-developer] On the fly configuration

[Kiran T <mah...@ho...>]

Is it possible to change the Proxool connection and pool configuration
properties without restarting the application server?

>Yes it is. Look at ProxoolFacade.updateConnectionPool(), and
>redefineConnectionPool().

...But I still have to restart my jvm to read the updated XML or property 
files. I typically want to increase or decrease the number of connections 
depending on the traffic. Can I do it without restarting the server( jvm) ?

_________________________________________________________________
From the hottest toys to tips on keeping fit this winter, you’ll find a 
range of helpful holiday info here.  
http://special.msn.com/network/happyholidays.armx

Re: [Proxool-developer] On the fly configuration

[Bill H. <bi...@lo...>]

Hi Kiran,

On Tue, 2003-11-18 at 23:11, sadf fdsf wrote:

> Is it possible to change the Proxool connection and pool configuration 
> properties without restarting the application server? 

Yes it is. Look at ProxoolFacade.updateConnectionPool(), and
redefineConnectionPool().

> If it is not implemented yet, is  this feature feasible in Proxool?

Yes it is feasible. We will be extending the functionality of the
AdminServlet after 0.9 is out to make this even easier. Making the
servlet update the pool is easy actually - the trick is to a) make it
persistable (so that the changes persist if the server restarts), and b)
allow for switching between different preset configurations (for
instance, switching to a backup database).

Regards,
Bill Horsman

[Proxool-developer] On the fly configuration

[sadf f. <mah...@ho...>]

Hi Bill,
Is it possible to change the Proxool connection and pool configuration 
properties without restarting the application server? For eg. having an 
admin form you can change the values.
If it is not implemented yet, is  this feature feasible in Proxool?

Thanks
Kiran

_________________________________________________________________
Gift-shop online from the comfort of home at MSN Shopping!  No crowds, free 
parking. http://shopping.msn.com

Re: [Proxool-developer] Summary of Cglib and Hibernate changes

[Bill H. <bi...@lo...>]

On Mon, 2003-11-17 at 23:59, Christian Nedregaard wrote:

> Could you post the CGLIB patch?

Certainly. You need the latest Cglib JAR from CVS too. 

http://proxool.sourceforge.net/download/proxool-cglib2.patch
http://proxool.sourceforge.net/download/cglib2-cvs.jar

If anyone has trouble applying the patch then I can send the changed
source files.

Bill

Re: [Proxool-developer] Summary of Cglib and Hibernate changes

[Christian N. <chr...@em...>]

Could you post the CGLIB patch?

----- Original Message -----
From: Bill Horsman <bi...@lo...>
Date: Mon, 17 Nov 2003 20:37:53 +0100
To: Proxool Developer <pro...@li...>
Subject: [Proxool-developer] Summary of Cglib and Hibernate changes

> Hi all,
> 
> I have been talking on the cglib and hibernate lists about the upcoming
> release of cglib 2 and what that means for Proxool. I thought I'd
> summarise the situation so everybody knows what is going on. It's a long
> email, so apologies in advance.
> 
> Cglib are about to release version 2. As Chris says below, this will be
> incompatible with version 1.
> 
> On Sun, 2003-11-16 at 19:08, Chris Nokleberg wrote: 
> 
> > [snip] this jar contains ASM 1.4, which is binary
> > incompatible with 1.3, so CGLIB 1.0 and 2.0 can no longer coexist
> > peacefully.
> 
> This means that if we are to upgrade to Cglib 2 then we need to make a
> few changes to Proxool (Chris has already provided a patch for this) and
> start distributing Cglib 2 with Proxool.
> 
> Okay. Why should we upgrade to Cglib 2? Well, anybody who decides to
> upgrade to Cglib 2 for other reasons is going to get problems. People
> who are likely to do that are users of Hibernate and Spring. Hibernate
> actually distribute Proxool (thanks to Martin Crawford) so they require
> Proxool to be updated in order to upgrade Cglib (which they are planning
> to do when they release 2.1 in the next 4 weeks).
> 
> So we've decided to upgrade Proxool to use Cglib 2 and will release a
> new version of Proxool shortly after Cglib 2 is released and (hopefully)
> shortly before Hibernate 2.1 is released.
> 
> The consequence of which is that Hibernate 2.0 and earlier users will
> not be able to upgrade Proxool without upgrading Hibernate. I think that
> is acceptable as long as we make people aware of that. Same goes for
> Spring.
> 
> It also means that anyone using Cglib in their own code will have to
> make changes in order to use the latest Proxool. We should probably
> provide some links in our own documentation about the best way to do
> that (without going into too much detail).
> 
> There is another option that we could think about too: providing our own
> ClassLoader. This would allow us to have Cglib 2 and Cglib 1 existing in
> certain situations. Not very pretty and it wouldn't solve the problem of
> the application code referencing Cglib 1.
> 
> Yet another option is that we use reflection to access Cglib and
> auto-detect which version is available. If Cglib 2 is unavailable we
> would resort to Cglib 1 and log a deprecation warning. This has
> benefits: 1) people can use which version of Cglib they want, and
> disadvantages: 1) code maintenance headache, 2) possible performance
> impact (although I suspect it would be minimal if done right).
> 
> There are four Proxool classes effected: ProxyConnection,
> ProxyDatabaseMetaData, ProxyFactory and ProxyStatement.
> 
> Phew. End of long message.
> 
> Regards,
> Bill Horsman
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

-- 
__________________________________________________________
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Search Smarter - get the new eXact Search Bar for free!
http://www.exactsearchbar.com/

[Proxool-developer] Summary of Cglib and Hibernate changes

[Bill H. <bi...@lo...>]

Hi all,

I have been talking on the cglib and hibernate lists about the upcoming
release of cglib 2 and what that means for Proxool. I thought I'd
summarise the situation so everybody knows what is going on. It's a long
email, so apologies in advance.

Cglib are about to release version 2. As Chris says below, this will be
incompatible with version 1.

On Sun, 2003-11-16 at 19:08, Chris Nokleberg wrote: 

> [snip] this jar contains ASM 1.4, which is binary
> incompatible with 1.3, so CGLIB 1.0 and 2.0 can no longer coexist
> peacefully.

This means that if we are to upgrade to Cglib 2 then we need to make a
few changes to Proxool (Chris has already provided a patch for this) and
start distributing Cglib 2 with Proxool.

Okay. Why should we upgrade to Cglib 2? Well, anybody who decides to
upgrade to Cglib 2 for other reasons is going to get problems. People
who are likely to do that are users of Hibernate and Spring. Hibernate
actually distribute Proxool (thanks to Martin Crawford) so they require
Proxool to be updated in order to upgrade Cglib (which they are planning
to do when they release 2.1 in the next 4 weeks).

So we've decided to upgrade Proxool to use Cglib 2 and will release a
new version of Proxool shortly after Cglib 2 is released and (hopefully)
shortly before Hibernate 2.1 is released.

The consequence of which is that Hibernate 2.0 and earlier users will
not be able to upgrade Proxool without upgrading Hibernate. I think that
is acceptable as long as we make people aware of that. Same goes for
Spring.

It also means that anyone using Cglib in their own code will have to
make changes in order to use the latest Proxool. We should probably
provide some links in our own documentation about the best way to do
that (without going into too much detail).

There is another option that we could think about too: providing our own
ClassLoader. This would allow us to have Cglib 2 and Cglib 1 existing in
certain situations. Not very pretty and it wouldn't solve the problem of
the application code referencing Cglib 1.

Yet another option is that we use reflection to access Cglib and
auto-detect which version is available. If Cglib 2 is unavailable we
would resort to Cglib 1 and log a deprecation warning. This has
benefits: 1) people can use which version of Cglib they want, and
disadvantages: 1) code maintenance headache, 2) possible performance
impact (although I suspect it would be minimal if done right).

There are four Proxool classes effected: ProxyConnection,
ProxyDatabaseMetaData, ProxyFactory and ProxyStatement.

Phew. End of long message.

Regards,
Bill Horsman

Re: [Proxool-developer] SQL statement from the Connection

[Bill H. <bi...@lo...>]

Hi Vick,

On Fri, 2003-11-14 at 15:51, xyz abc wrote:

> Unfortunately, onExecute() never "gets completed" if there is a DB Block.
> Would it be more effective to split the onExecute() into 
> onExecuteStart(String command) and onExecuteFinish(String command, long 
> elapsedtime)?

Yep, that's a good point. It would mean changing the public API for
Proxool which isn't something we do lightly though. 

There is another option for you which might work. Have you investigated
ProxoolFacade.getSnapshot()? This will give you a list of all
connections and tell you how long each one has been active for. See
ConnectionInfoIF.getTimeLastStartActive().

If you are in a servlet environment then you can see this information by
using the bundled AdminServlet.

Unfortunately, this doesn't tell you the SQL it was performing but it
does tell you the name of the thread that is using that connection -
ConnectionInfoIF.getRequester().

I think the best thing to do would be to add a new method to
ConnectionInfoIF called getSql() that tells you what SQL is currently
being executed. That would be really interesting - I can't believe I
haven't thought of it before. And because ConnectionInfoIF is
implemented internally it could be done without breaking backwards
compatibility.

Performance impact would be negligible. You would have to turn on the
"trace" property to see this extra information anyway.

Anybody any thoughts on this?

Cheers,
Bill

Re: [Proxool-developer] SQL statement from the Connection

[xyz a. <vik...@ho...>]

Hi Bill,
Thanks for the information. Yes, onExecute() does display the SQL query.

In my case, the only reason I am interested in this method would be to 
monitor/investigate the DB Blocks. I would be interested in finding whoch 
query caused the DB blocks.
Unfortunately, onExecute() never "gets completed" if there is a DB Block.
Would it be more effective to split the onExecute() into 
onExecuteStart(String command) and onExecuteFinish(String command, long 
elapsedtime)?


>From: Bill Horsman <bi...@lo...>
>To: xyz abc <vik...@ho...>
>CC: Proxool <pro...@li...>
>Subject: Re: [Proxool-developer] SQL statement from the Connection
>Date: Thu, 13 Nov 2003 23:42:47 +0000
>
>Hi Vick,
>
>On Thu, 2003-11-13 at 19:56, xyz abc wrote:
>
> > I was looking at ConnectionListenerIF's onExecute method. The note says 
>that
> > command is not fully implemented at this stage. At some point it might
> > represent the SQL that is sent to the database (or the procedure call 
>that
> > was used).
>
>I'm pleased to say that the documentation is wrong. It *is* implemented
>:)
>
>The SQL should pretty accurately represent what was sent to the
>database. Almost like a journal. I say things like "should", and
>"pretty" and "almost" because it's not thoroughly tested. There are lots
>of ways of constructing statements and executing SQL in the JDBC API and
>we've have attempted to trap them all.
>
>So, my recommendation is: please use the onExecute() method and let us
>know if you have any problems. I have not come across any yet.
>
>The onExecute() method is the only way to extract the SQL from the
>connection. Note that it might contain a semicolon delimited list of
>queries if a batch execute was used.
>
>Regards.
>Bill Horsman
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer

_________________________________________________________________
Concerned that messages may bounce because your Hotmail account is over 
limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es

Re: [Proxool-developer] SQL statement from the Conncetion

[Bill H. <bi...@lo...>]

Hi Vick,

On Thu, 2003-11-13 at 19:56, xyz abc wrote:

> I was looking at ConnectionListenerIF's onExecute method. The note says that
> command is not fully implemented at this stage. At some point it might 
> represent the SQL that is sent to the database (or the procedure call that 
> was used). 

I'm pleased to say that the documentation is wrong. It *is* implemented
:)

The SQL should pretty accurately represent what was sent to the
database. Almost like a journal. I say things like "should", and
"pretty" and "almost" because it's not thoroughly tested. There are lots
of ways of constructing statements and executing SQL in the JDBC API and
we've have attempted to trap them all. 

So, my recommendation is: please use the onExecute() method and let us
know if you have any problems. I have not come across any yet.

The onExecute() method is the only way to extract the SQL from the
connection. Note that it might contain a semicolon delimited list of
queries if a batch execute was used.

Regards.
Bill Horsman

[Proxool-developer] SQL statement from the Conncetion

[xyz a. <vik...@ho...>]

Hello ,
I was looking at ConnectionListenerIF's onExecute method. The note says that
command is not fully implemented at this stage. At some point it might 
represent the SQL that is sent to the database (or the procedure call that 
was used). Is that something being considered in a very near future? If we 
implement the method,is there any way to get the SQl query out of a 
connection associaited with that query( through Statemnent). 
java.sql.Connection class does not have a  method like conn.getStatement(). 
Would such methods be possible in ProxyConnection?

Thanks in advance
Vick

_________________________________________________________________
Is your computer infected with a virus?  Find out with a FREE computer virus 
scan from McAfee.  Take the FreeScan now! 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

[Proxool-developer] Proxool 0.8.2

[Bill H. <bi...@lo...>]

Hi all,

0.8.2 Fixes a bug which meant that no delegate driver properties (other
than username and password) were being passed onto the delegate driver.
If you don't pass on any delegate properties then you won't be affected.
See http://proxool.sourceforge.net for details

(Again, sorry for cross post to all three lists)

Regards,
Bill Horsman

Re: [Proxool-developer] CGLIB 2

[Bill H. <bi...@lo...>]

After a lot of thought, here's the schedule I propose:

5-Nov:
0.8.2 is released
CGLIB-2 branch is created

7-Nov:
0.8.2-cglib-2-b1 is released (from CGLIB-2 branch but with patch for
cglib 2 and new Enhancer API)

20-Nov:
0.9.0 release process starts (beta, then release candidates)

27-Nov:
0.9.0 final

Note 1. Depending on release schedule of CGLIB 2 and feedback from the
Hibernate team the CGLIB-2 branch may or may not be included in 0.9.0.

Note 2. If Hibernate looks like it will release 2.1 final before 0.9.0
then we will release 0.8.3 in time to be included in their release. This
will include the cglib-2 patch, but not the DataSource stuff. 

Note 3. The reason why we are producing a beta release of Proxool with
cglib-2 support before cglib-2 is finally released is that Hibernate
want to include cglib-2 in their beta releases of 2.1. And Hibernate
have a dependency on Proxool (we are one of their bundled JDBC pools). 

Bill

Re: [Proxool-developer] CGLIB 2

[Christian N. <chr...@em...>]

Soooo....

Lets aim for this optimal seqence of releases (all from HEAD):

0.8.2 - Bugfix
0.8.3 - CGLIB 2
0.9   - DataSource (++?)

I'll keep the DataSource stuff locally until after 0.8.3.

If the CGLIB 2 stuff proves to be a blocker for 0.9 we will review the problem. Aiight?


CHR

----- Original Message -----
From: Bill Horsman <bi...@lo...>
Date: Tue, 04 Nov 2003 09:54:54 +0000
To: Christian Nedregaard <chr...@em...>
Subject: Re: [Proxool-developer] CGLIB 2

> > Why dont we just aim for this sequence of releases in HEAD:
> > 
> > 0.8.3 - bugfix
> > 0.8.4 - CGLIB 2
> > 0.9   - DataSource (++?)
> 
> First of all, I made a mistake. The bug fix release will be 0.8.2.
> 
> The only reason I hesitate about releasing 0.8.4 (er, I mean 0.8.3)
> before 0.9.0 is it means we can't release our DataSource code until
> cglib2 is released. I don't like that loss of control. Let me talk to 
> Chris at cglib and see what he thinks about timing.
> 
> > 1) We will have to make our branch from the v0-8-2 tag. This is
> > confusing. Normal procedure would have been to create a bugfix branch
> > on the v0-8 release.
> 
> Er, we could still do that right? But it would then be very wise to
> merge in the bug fixes from 0.8.1/2. 
> 
> > 2) Branching in general leads to confusion. People tend to forget wich
> > branch they work in, forget to merge etc. etc.
> 
> Tell me about it. If we can avoid it, then fine.
> 
> > We will need a branch if you need to checkin unfinished CGLIB 2 stuff
> > before the 0.8.3 release.
> 
> That can be avoided. 0.8.3 (er, I mean 0.8.2) will definitely be before
> cglib2 is released. Probably.
> 
> [snip]
> > cvs rtag -b -r v0-8-2 v0-8-2-PATCH proxool
> [snip]
> > 1) Tag the merge point:
> > cvs -q rtag -F -r v0-8-2-PATCH v0-8-2-PATCH-MERGED proxool 
> > 
> > 2) Merge in from the "v0-8-2-PATCH" branch to HEAD:
> > cvs update -d -j v0-8-2-PATCH
> 
> Thanks for clarifying that. Merging scares me :)
> 
> > We don't need a separate branch for the CGLIB stuff if I hold my
> > DataSource checkins right? Alternatively I can keep it in the sandbox.
> 
> I think you might run into problems with keeping it in the sandbox.
> You'll need to reference it in ProxoolFacade, I would think. I can't
> think of a nice way round that.
> 
> Cheers,
> Bill
> 
> P.S. I'm very excited about the DataSource code :)
> 

-- 
__________________________________________________________
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

Re: [Proxool-developer] CGLIB 2

[Bill H. <bi...@lo...>]

> Why dont we just aim for this sequence of releases in HEAD:
> 
> 0.8.3 - bugfix
> 0.8.4 - CGLIB 2
> 0.9   - DataSource (++?)

First of all, I made a mistake. The bug fix release will be 0.8.2.

The only reason I hesitate about releasing 0.8.4 (er, I mean 0.8.3)
before 0.9.0 is it means we can't release our DataSource code until
cglib2 is released. I don't like that loss of control. Let me talk to 
Chris at cglib and see what he thinks about timing.

> 1) We will have to make our branch from the v0-8-2 tag. This is
> confusing. Normal procedure would have been to create a bugfix branch
> on the v0-8 release.

Er, we could still do that right? But it would then be very wise to
merge in the bug fixes from 0.8.1/2. 

> 2) Branching in general leads to confusion. People tend to forget wich
> branch they work in, forget to merge etc. etc.

Tell me about it. If we can avoid it, then fine.

> We will need a branch if you need to checkin unfinished CGLIB 2 stuff
> before the 0.8.3 release.

That can be avoided. 0.8.3 (er, I mean 0.8.2) will definitely be before
cglib2 is released. Probably.

[snip]
> cvs rtag -b -r v0-8-2 v0-8-2-PATCH proxool
[snip]
> 1) Tag the merge point:
> cvs -q rtag -F -r v0-8-2-PATCH v0-8-2-PATCH-MERGED proxool 
> 
> 2) Merge in from the "v0-8-2-PATCH" branch to HEAD:
> cvs update -d -j v0-8-2-PATCH

Thanks for clarifying that. Merging scares me :)

> We don't need a separate branch for the CGLIB stuff if I hold my
> DataSource checkins right? Alternatively I can keep it in the sandbox.

I think you might run into problems with keeping it in the sandbox.
You'll need to reference it in ProxoolFacade, I would think. I can't
think of a nice way round that.

Cheers,
Bill

P.S. I'm very excited about the DataSource code :)

Re: [Proxool-developer] CGLIB 2

[Christian N. <chr...@em...>]

Is this really neccecary?

I can hold my DataSource checkins until after the CGLIB 2 related release.

Why dont we just aim for this sequence of releases in HEAD:

0.8.3 - bugfix
0.8.4 - CGLIB 2
0.9   - DataSource (++?)

I'm negative to a branch (and certanly to two) for a couple fof reasons:
1) We will have to make our branch from the v0-8-2 tag. This is confusing. Normal procedure would have been to create a bugfix branch on the v0-8 release.

2) Branching in general leads to confusion. People tend to forget wich branch they work in, forget to merge etc. etc.


We will need a branch if you need to checkin unfinished CGLIB 2 stuff before the 0.8.3 release.

If so I suggest we use the following procedure.

Create a "v0-8-2-PATCH" branch based on the v0-8-2 release:
cvs rtag -b -r v0-8-2 v0-8-2-PATCH proxool

All fixes aimed for v0-8-3 will be checked into this branch, and v0-8-3 will be tagged and released from it.
When we have finished in the branch (probably after 0.8.3) we'll need to merge in to HEAD. This is a two step process:

1) Tag the merge point:
cvs -q rtag -F -r v0-8-2-PATCH v0-8-2-PATCH-MERGED proxool 

2) Merge in from the "v0-8-2-PATCH" branch to HEAD:
cvs update -d -j v0-8-2-PATCH

We don't need a separate branch for the CGLIB stuff if I hold my DataSource checkins right? Alternatively I can keep it in the sandbox.

CHR


----- Original Message -----
From: Bill Horsman <bi...@lo...>
Date: Mon, 03 Nov 2003 14:32:32 +0000
To: Proxool Developer List <pro...@li...>
Subject: [Proxool-developer] CGLIB 2

> Hi,
> 
> Chris Nokleberg from the cglib project has kindly written a patch to get
> Proxool working with the new, faster Enhancer and the latest version of
> cglib (we use cglib for proxy support).
> 
> Cglib 2 is binary incompatible with cglib 1 so they have changed the
> package structure slightly. The upshot of which is that the Hibernate
> project (recently part of the JBoss project) wants to use cglib 2 in its
> next release. They don't particularly want to ship both cglib 1 and 2 so
> they have asked us to produce a release for cglib 2.
> 
> I don't know exactly when this will all happen. Sometime in the next few
> weeks cglib 2 will be released. And then sometime after that Hibernate
> will be released. I would like to make a release of Proxool inbetween
> those two events so that Hibernate can ship the latest Proxool.
> 
> I feel we will also be releasing 0.8.3 sometime soon and 0.9.0 (with
> DataSource support) is on the horizon (Christian has taken a look at
> this). I don't want to mess up our release schedule with other events
> beyond our control, so I think we need to do some clever branching.
> 
> I propose a branch for 0.8.3 that is a bug fix branch. We can work on
> the DataSource code in the head branch. And another branch for cglib 2
> (probably based on 0.8.3) Damn, I think we need a picture here.
> 
> Any comments?
> 
> Bill
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

-- 
__________________________________________________________
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

[Proxool-developer] CGLIB 2

[Bill H. <bi...@lo...>]

Hi,

Chris Nokleberg from the cglib project has kindly written a patch to get
Proxool working with the new, faster Enhancer and the latest version of
cglib (we use cglib for proxy support).

Cglib 2 is binary incompatible with cglib 1 so they have changed the
package structure slightly. The upshot of which is that the Hibernate
project (recently part of the JBoss project) wants to use cglib 2 in its
next release. They don't particularly want to ship both cglib 1 and 2 so
they have asked us to produce a release for cglib 2.

I don't know exactly when this will all happen. Sometime in the next few
weeks cglib 2 will be released. And then sometime after that Hibernate
will be released. I would like to make a release of Proxool inbetween
those two events so that Hibernate can ship the latest Proxool.

I feel we will also be releasing 0.8.3 sometime soon and 0.9.0 (with
DataSource support) is on the horizon (Christian has taken a look at
this). I don't want to mess up our release schedule with other events
beyond our control, so I think we need to do some clever branching.

I propose a branch for 0.8.3 that is a bug fix branch. We can work on
the DataSource code in the head branch. And another branch for cglib 2
(probably based on 0.8.3) Damn, I think we need a picture here.

Any comments?

Bill

Re: [Proxool-developer] Re Transactions in Proxool

[Bill H. <bi...@lo...>]

On Fri, 2003-10-31 at 05:04, Easwaran wrote:

> How to enable transactions in proxool?

The simple answer is: the same way that you do without Proxool. Proxool
doesn't provide any transaction functionality but it does allow you to
use any provided by your other (delegate) JDBC driver. Which, in turn,
probably relies on the database to provide transactions.

Take a look here:
http://java.sun.com/docs/books/tutorial/jdbc/basics/transactions.html

Good luck,
Bill Horsman

[Proxool-developer] Re Transactions in Proxool

[Easwaran <eas...@as...>]

How to enable transactions in proxool?
 
 
Easwaran Narayana Iyer
System Architect
Asophia Asia Systems Pte Ltd
Singapore 416259
Phone: 68429309
Mobile: 98246040
 

[Proxool-developer] Proxool 0.8.1

[Bill H. <bi...@lo...>]

Sorry for cross posting to all three lists. There seems to be quite a
few people on the user and developer lists that probably want to know
about new releases, but don't belong to the announce list. So...

---

27 October 2003 - 0.8.1 Fixes a bug that crept into 0.8.0. It caused a
NullPointerException during SQL logging if you built your statements in
a certain way. You should upgrade to 0.8.1. We are sorry for any
inconvenience. See change log for details.

Thanks to Mike Rosseel for spotting the problem and reporting it so
quickly. 

Regards,
Bill Horsman