proxool-developer — Developer's discussion list

[Proxool-developer] Proxool 0.8.0

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

Hi all,

Apologies to anyone who is receiving this twice - there are a few people
on the dev list not on the user list. Here is an announcement from the
user list:
---

26 October 2003 - 0.8.0 has been a long time coming, thank you for your
patience. It is the first release with JDK independence. Or more
precisely, Proxool now runs, out of the box, on JDK1.2 and up. (We used
to support JDK1.2 with a series of Ant applied patches which was a bit
messy). We now make use of cglib's proxy code to do this. Proxool is
also now available as a JMX component to help you to control it even
more easily. There have been quite a few bug fixes and useful
enhancements too. All users are recommended to upgrade to 0.8.0. See
change log for details.

Enjoy,
Bill Horsman

[Proxool-developer] JMX should be finished

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

All jmx tests pass now. The problem was a combination of bugs in both the Proxool JMX bean and in Proxool proper.

I am still not able to null out string properties when testing the JMX bean in JBoss 3.2.1, but the spesific test for this in Proxool passes, so I'm inclined to believe that this is a JBoss bug.

Bill:
The "jmx-agent-id" configration property is not documentet in the RC.
Could you add the following documentation?

-----
jmx-agent-id:
A comma separated list of JMX agent ids (as used by MBeanServerFactory.findMBeanServer(String agentId) ) to register the pool to. This property is only used if the "jmx" property is set to "true". All registered JMX servers will be used if this property is not set.   
-----

There is also a bug in the documentation for the "jmx" property:

object name: "Proxool:type=Pool, name=". 

...should be changed to:

object name: "Proxool:type=Pool, name=<alias>".

CHR 
-- 
__________________________________________________________
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] jmx properties are being sendt to the driver?

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

Hi CHR,

On Tue, 2003-10-14 at 00:08, Christian Nedregaard wrote:

> I hope to get this done tomorrow. If I can't make my test work I'll
> remove some unessential JMX functionality from this release. So the
> JMX stuff should be ready really soon one way or another.

Great. I can see 0.8.0 on the horizon now.

> It seems like the jmx properties are being interpreted as driver properties:
> 
> 60 [testMultipleAgents] DEBUG org.logicalcobwebs.proxool.testMultipleAgents  - Delegating property to driver: proxool.jmx-agent-id=testAgent1, testAgent2
> 60 [testMultipleAgents] DEBUG org.logicalcobwebs.proxool.testMultipleAgents  - Delegating property to driver: proxool.jmx=true

A proxool prefix doesn't guarantee it doesn't get passed on to the
delegate driver. The proxool prefix just helps us to have unique
property names. What's important is whether the ConnectionPoolDefinition
class recognises it. "proxool.jmx" is recognised. "proxool.jmx-agent-id"
is not. Should that property be passed to somewhere? If so, it would
mean a change to ConnectionPoolDefinition to treat it as a special case
(which is fine).

Bill

[Proxool-developer] jmx properties are being sendt to the driver?

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

I'm trying to finalize the JMX stuff, but still have some failing test (not committed to cvs yet).

I hope to get this done tomorrow. If I can't make my test work I'll remove some unessential JMX functionality from this release. So the JMX stuff should be ready really soon one way or another.

In the meantime, Bill, maybe you can check this out:

It seems like the jmx properties are being interpreted as driver properties:

60 [testMultipleAgents] DEBUG org.logicalcobwebs.proxool.testMultipleAgents  - Delegating property to driver: proxool.jmx-agent-id=testAgent1, testAgent2
60 [testMultipleAgents] DEBUG org.logicalcobwebs.proxool.testMultipleAgents  - Delegating property to driver: proxool.jmx=true

CHR
-- 
__________________________________________________________
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] Logging in Java 1.4

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

Proxool uses a logging strategy based on Jakarta Commons Logging:
http://proxool.sourceforge.net/logging.html
http://jakarta.apache.org/commons/logging.html

Commons logging will try to figure out automatically what log system to use. If the Log4J library is available it will be chosen, then if JDK 1.4 is available it will be chosen.

You need to do two things:

1) Configure JDK 1.4 logging globally
This can be done through the LogManager (http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/LogManager.html), for instance by loading configuration properties from a file using the readConfiguration(InputStream ins) method.

2) Make sure that JDK 1.4 logging is chosen in favour of Log4J.
You don't have to do anything if Log4J is not available in the classpath of your app.
If Log4J is available you will have to explicitely tell Proxool to use a JDK 1.4 logger.
You do this by setting this property:
org.logicalcobwebs.logging.Log=org.logicalcobwebs.logging.impl.Jdk14Logger

You can set it as a system property
Commandline:
java -Dorg.logicalcobwebs.logging.Log=org.logicalcobwebs.logging.impl.Jdk14Logger
Programatically:
System.setProperty("org.logicalcobwebs.logging.Log", "org.logicalcobwebs.logging.impl.Jdk14Logger");

...or you can set it directly on Proxools LogFactory:
org.logicalcobwebs.logging.LogFactory.getFactory().setAttribute("org.logicalcobwebs.logging.Log", "org.logicalcobwebs.logging.impl.Jdk14Logger")

CHR 


----- Original Message -----
From: "Cochran, Keith" <Kei...@tr...>
Date: Mon, 6 Oct 2003 15:55:14 -0600
To: "''pro...@li...''" <pro...@li...>
Subject: [Proxool-developer] Logging in Java 1.4

> Do you have any examples of how to log Proxool using the
> 1.4 style of logging.  I know how to set up logging and use it
> in 1.4, but how do I get the logging info out of Proxool to
> go to it's own logger?
> -----------------------------------------
> If I set up a logger as such:
> 
>   Logger logger = Logger.getLogger("com.my.logger");
>   FileHandler  handler = new FileHandler("logFilename_%g.log", 1000000, 10,
> false);
>   handler.setFormatter(new SimpleFormatter());
>   Logger logger.addHandler(handler);  
>   logger.setLevel(Level.FINE);
>   logger.logp(Level.WARNING, "MyClass", "main", "Some Warning message");
> 
> ...this prints out a warning message to my log file no problem.
> 
> How do I get the Proxool messages to go to a logger instead of stdout?
> 
> Thanks!
> -Keith
> 
> _______________________________________________
> Keith G. Cochran
> New Technology Development - The TriZetto Group, Inc.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Logging in Java 1.4

[Cochran, K. <Kei...@tr...>]

Do you have any examples of how to log Proxool using the
1.4 style of logging.  I know how to set up logging and use it
in 1.4, but how do I get the logging info out of Proxool to
go to it's own logger?
-----------------------------------------
If I set up a logger as such:

  Logger logger = Logger.getLogger("com.my.logger");
  FileHandler  handler = new FileHandler("logFilename_%g.log", 1000000, 10,
false);
  handler.setFormatter(new SimpleFormatter());
  Logger logger.addHandler(handler);  
  logger.setLevel(Level.FINE);
  logger.logp(Level.WARNING, "MyClass", "main", "Some Warning message");

...this prints out a warning message to my log file no problem.

How do I get the Proxool messages to go to a logger instead of stdout?

Thanks!
-Keith

_______________________________________________
Keith G. Cochran
New Technology Development - The TriZetto Group, Inc.

[Proxool-developer] 0.8.0RC2

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

Hi all,

I've just made a preview release of 0.8.0RC2. You can find it here:

http://proxool.sourceforge.net/dev/index.html

The download page will give you access to the binary and source
distributions.

It would be really helpful if people could try it out in any sort of
environment they can. Mark Eagle and I have sorted out a problem with
RC1 inside WebSphere Studio Application Developer (WSAD) to do with
class loading. 

This is a really important release for us because of the switch away
from the JDK proxy to CGLIB's library - it enables us to distribute one
product for all JDKs (JDK 1.2+). Plus Christian's JMX code.

There are also numerous bug fixes since 0.7.2 (and a few since
0.8.0RC1). Sorry, the changelog only lists the changes since 0.7.2 and
doesn't show the differences since 0.8.0RC1 - I'll get that right next
time).

If all goes well, I intend to release 0.8.0 final sometime around the 20
October (I'm on holiday next week).

As well as testing the code, please also be on the lookout for
missing/extra files in the distributions and corrections in the doc. 

Happy Testing!
Regards,
Bill Horsman

Re: [Proxool-developer] 0.8.0RC1 Update

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

Hi all,

On Tue, 2003-09-16 at 17:39, Bill Horsman wrote:

> 1) We've had reports of CodeGenerationErrors from the cglib (proxy)
> library under IBM's JVM. We'd like to hear from anyone else experiencing
> this.

I've tried to reproduce this using 

J2RE 1.4.1 IBM build cxia32141-20030522 (JIT enabled: jitc)
J2RE 1.3.1 IBM build cxia32131-20030618 (JIT enabled: jitc)

Both running on Mandrake 9.1 and all the unit tests passed fine.

The problem was reported in conjunction with Hibernate and so we have
wondered about ClassLoaders. I don't have a Hibernate environment setup
but it looks like that would be a wise things to do.

It would be nice to get this sorted out - it's the only thing (apart
from some doc) holding up 0.8.

Cheers,
Bill

[Proxool-developer] 0.8.0RC1 Update

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

Hi all,

Just to keep you all updated on some of the feedback we've had on the
release candidate.

1) We've had reports of CodeGenerationErrors from the cglib (proxy)
library under IBM's JVM. We'd like to hear from anyone else experiencing
this.

2) There was a bug in the JDK14 Logger which caused problems for anyone
running JDK1.4 without having one of either Log4J or LogKit configured.
This is fixed in CVS, but a workaround is to add Log4J or LogKit.

When we've explored #1 a bit more we will more than likely come up with
RC2.

Cheers,
Bill Horsman

Re: [Proxool-developer] simultaneous-build-throttle vs maximum-new-connections

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

Christian Nedregaard wrote:

>I think at one point the maximum-new-connections property was deprecated in favour of simultaneous-build-throttle.
>
>The RC only documents maximum-new-connections. Is this a doc bug?
>  
>
Yep, well spotted.

>IMHO we should undeprecate maximum-new-connections and throw away simultaneous-build-throttle as that property name is no easyer to understand than the old one. 
>  
>
The thing I like about simultaneous-build-throttle is that it can't be 
confused with maximum-connection-count. The word "throttle" is quite 
descriptive, even if "simultaneous-build" is a bit obscure. I think 
we'll keep it, if you don't mind.

>The doc for maximum-new-connections seems to have been made more understandable, maybe that is enough?
>  
>
I'm glad it's more understandable :) It's a strange concept altogether. 
I'm not even sure if it's relevant anymore. We put it there when we were 
struggling to get JDK1.many-years-ago to stay alive when our web server 
was suffering. But I suppose it might be relevant for people still 
running JDK1.many-years-ago.

Bill

Re: [Proxool-developer] JMX doc

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

Chr,

>I don't think it is nessecary with a separate doc page for the JMX stuff. Bill: Could you add the following to the properties doc?
>
>jmx
>If true the pool will be registered as an MBean to a JMX server with the following object name: "Proxool:type=Pool, name=<alias>". Default: false
>
>jmx-agent-id
>A comma separated list of JMX agent names to register the pool in. Default is null (the pool will be registered with the default JMX agent). This attribute is only applicable if the 'jmx' property is set to 'true'.
>  
>
Yep, I'll do that.

Bill

[Proxool-developer] JMX doc

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

I have added the wrap-fatal-sql-exceptions, statistics and statistics-log-level properties to the Proxool MBean.

I have found a problem that needs further investigation: 
In JBoss JMX I seem to be unable to delete text properties. I'll have a look at that on tuesday.

I don't think it is nessecary with a separate doc page for the JMX stuff. Bill: Could you add the following to the properties doc?

jmx
If true the pool will be registered as an MBean to a JMX server with the following object name: "Proxool:type=Pool, name=<alias>". Default: false

jmx-agent-id
A comma separated list of JMX agent names to register the pool in. Default is null (the pool will be registered with the default JMX agent). This attribute is only applicable if the 'jmx' property is set to 'true'.

CHR

-- 
__________________________________________________________
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] Test failure

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

I keep getting this JUnit failure:
testConnectionInfo(org.logicalcobwebs.proxool.ConnectionInfoTest)
junit.framework.AssertionFailedError: connectionInfo count expected:<3> but was:
<2>

Any ideas?

CHR

-- 
__________________________________________________________
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] simultaneous-build-throttle vs maximum-new-connections

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

I think at one point the maximum-new-connections property was deprecated in favour of simultaneous-build-throttle.

The RC only documents maximum-new-connections. Is this a doc bug?

IMHO we should undeprecate maximum-new-connections and throw away simultaneous-build-throttle as that property name is no easyer to understand than the old one. 

The doc for maximum-new-connections seems to have been made more understandable, maybe that is enough?

CHR

-- 
__________________________________________________________
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] RE: Proxool 0.8.0RC1 additional dependency

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

[Switching to dev-list]


Hi Mark. 

This might be jar-mageddon. Did you include the CGLIB jar in Proxool as well as in Hibernate, or are they in the same webapp?

If you have two CGLIB jars could you try to remove them both, and then add one to the Websphere root classloader? I've never used Websphere but I guess it has a global 'lib' directory or somehting?

Another thing you might try is to use this alternative build of CGLIB:
http://prdownloads.sourceforge.net/cglib/cglib-bcel-1.0.jar?download

It uses BCEL as a backend instead of ASM.

Bill:
If this is jar-mageddon we might consider cannibalizing the code into Proxool like we have done with Commons Logging. By the way: Are there any IBM jdks in the SourceForge test cluster?

CHR




> -----Original Message-----
> From: meagle [mailto:me...@me...]
> Sent: 12. september 2003 02:37
> To: Bill Horsman
> Subject: Re: Proxool 0.8.0RC1 additional dependency
> 
> 
> Bill,
> 
> I am using JDK 1.3.1.  I am not at my work pc, so this might 
> be the IBM
> version of the JDK.  We use WebSphere Application Developer 
> for our IDE.  I
> compared the cglib-asm jar that I have with the one that you 
> suggested in
> the link.  They seem to be identical.  Also, Hibernate has a 
> file in their
> lib directory that has a list of all of the jars they use 
> with versions.
> They claim that it is version 1.0.  I will try some more 
> tommorrow.  I am
> stuck with the JDK because our production WebSphere server 
> will not work
> with anything higher than JDK 1.3.1.  I am willing to help you find a
> resolution to this and will experiment more tommorrow.
> 
> Thanks,
> 
> Mark
> 
> 
> ----- Original Message -----
> From: "Bill Horsman" <bi...@lo...>
> To: "Mark Eagle" <me...@me...>
> Cc: "Christian Nedregård" <chr...@em...>
> Sent: Thursday, September 11, 2003 7:29 PM
> Subject: Re: Proxool 0.8.0RC1 additional dependency
> 
> 
> > Hi Mark,
> >
> > On Thu, 2003-09-11 at 20:08, Mark Eagle wrote:
> >
> > [snip]
> > > 2003-09-11 15:01:29,422 ERROR logicalcobwebs.proxool.dvlp 
> -> Couldn't
> get
> > > connection
> > > net.sf.cglib.CodeGenerationException: net.sf.cglib.Proxy$ProxyImpl
> > > at 
> net.sf.cglib.EnhancerGenerator.<init>(EnhancerGenerator.java:145)
> > > at net.sf.cglib.Enhancer.enhanceClassHelper(Enhancer.java:239)
> > > at net.sf.cglib.Enhancer.enhanceClass(Enhancer.java:200)
> > > at net.sf.cglib.Proxy.getProxyClass(Proxy.java:106)
> > > at net.sf.cglib.Proxy.newProxyInstance(Proxy.java:117)
> > > at
> > >
> org.logicalcobwebs.proxool.ProxyFactory.buildProxyConnection(P
> roxyFactory.ja
> > > va:42)
> >
> > It doesn't give us many clues does it? What JDK are you 
> using? And can
> > you confirm that your cglib JAR is the same as ours? I 
> would hope that
> > there wouldn't be a conflict but it would be nice to rule that out.
> >
> > I'm copying this to Christian Nedregård who coded the 
> switch to cglib.
> >
> > Thanks for taking the time to help us with this release.
> >
> > Regards,
> > Bill
> >
> 
-- 
__________________________________________________________
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] more than one pool

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

Hi Keith,

On Thu, 2003-09-11 at 19:42, Cochran, Keith wrote:

> I figured it out.  My Relativity driver does not like the following:
> 
>     info.setProperty("house-keeping-sleep-time", String.valueOf(30 * 1000));
>     info.setProperty("proxool.house-keeping-test-sql",
>                      "SELECT eenmbr from elgemp where eenmbr = 1");
> 
> This is a valid SQL statement for my db, but the house-keeping-sleep-time
> parameter
> causes a null pointer exception for some reason.

That is weird. Just out of interest, does your JDBC driver support you
using that same SQL statement? I just want to confirm that this is a
Relativity quirk and not something precipitated by Proxool. For your
information, the house keeper just does this:

  String sql = definition.getHouseKeepingTestSql();
  if (sql != null && sql.length() > 0) {
    // A Test Statement has been provided. Execute it!
    boolean testResult = false;
    testResult = testStatement.execute(sql);
  }

I might look into this some more. I would expect a NullPointerException
during housekeeping to simply log the error and throw away the
connection. It shouldn't pass that exception to the user.

Ah, now I see. The house keeper only reacts gracefully to SQLExceptions.
It doesn't expect RuntimeExceptions. I will fix that. I would think that
any exception thrown during the execution of the test SQL should simply
result in that connection being removed from the pool and the error
logged. Nothing more.

Look out for that fix in the soon-to-be-released 0.8.0.

Cheers,
Bill

[Proxool-developer] Proxool 0.8.0RC1 additional dependency

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

Hi all,

Sorry, I forgot to say. 0.8.0RC1 relies on the CGLIB project and you
need to add the cglib-asm-1.0.jar to your classpath. You can find it
here:

http://proxool.sourceforge.net/dev/download/cglib-asm-1.0.jar

This will be part of the usual binary and source downloads when we make
the final 0.8.0 release.

Regards,
Bill Horsman

[Proxool-developer] 0.8.0RC1

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

Hi all,

I have just put 0.8.0RC1 onto the "dev" web site:

http://proxool.sourceforge.net/dev/index.html

Go to the download page to pick up the JAR file. Your testing is very
much appreciated.

This isn't a full release. It has been unit tested and deployed in one
application. There are no known bugs but you should treat it with
caution at this stage.

There is no full download available - all you have is the JAR file. You
can check out the code from CVS if you wish. All the documentation is on
the web site mentioned above.

The final release will be made when the JMX documentation is available
and we have had no bad reports from this release candidate.

Cheers,
Bill Horsman

Re: [Proxool-developer] Proxool 1.2 compatible

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

Good work Christian,

On Thu, 2003-09-11 at 09:20, Christian Nedregaard wrote:

> The Proxool code should now be completely compatible with jdk 1.2.
[snip]
> We'll now spend some time testing for robustness and speed.

All the unit tests run successfully under:
  JDK1.2.2_016
  JDK1.3.1_09
  JDK1.4.2_01

The next step is to drop it into a few systems and see whether it
behaves. Let me know if you have a test environment for 0.8.0 anyone.
I'll put a beta JAR up on the web site later today.

> I guess this means we can remomve the 1.2 tree Bill?

Yes, I'll do that :) Yipee.

Bill

[Proxool-developer] Proxool 1.2 compatible

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

The Proxool code should now be completely compatible with jdk 1.2.

ShutdownHook and Jdk14Logger are accessed through reflection, the Timer code has been replaced by the Thread approach from the 1.2 code tree and all dynamic proxying are done through CGLIB.

We'll now spend some time testing for robustness and speed.

I guess this means we can remomve the 1.2 tree Bill?

CHR

-- 
__________________________________________________________
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] JDK independence

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

> > Another compelling approach is to simply stop using the JDK Proxy and
> > use the CGLIB Proxy all over. If we go that route we can throw away
> > the 1.2 source tree today...
> 
> That sounds fine.

Oki.

Will have a go tonight.

CHR


-- 
__________________________________________________________
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] JDK independence

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

Hi Christian,

On Tue, 2003-09-09 at 10:58, Christian Nedregaard wrote:

> The same strategy will be applied to the ShutdownHook except that we
> will not offer any alternative implementation for 1.2. We'll simply
> document that 1.2 users will have to take care of the shutdown
> expilcitly.

That's done and committed to CVS.

> CGLIB (http://cglib.sourceforge.net/)
[snip]
> CGLIB added a slight overhead compared to JDK Proxy calls, but it was very tiny. 

Yep, I don't think that overhead is significant.

> I guess the best solution would be to use a similar approach to that
> mentioned above: Use Proxy for 1.3+ and CGLIB for 1.2. The problem
> here is that I have not figured out how to make a class implement the
> InnvocationHandler *runtime* with CGLIB. This is a simple method call
> in Javassist. I'll investigate further...

> Another compelling approach is to simply stop using the JDK Proxy and
> use the CGLIB Proxy all over. If we go that route we can throw away
> the 1.2 source tree today...

That sounds fine.

Just to throw another idea into the confusion: Jakarta Commons' Logging
uses a compromise solution. Their source only compiles with JDK1.4
(because of the reference to JDK1.4's logging), but it works well under
JDK1.2+ because it just ignores that class if it isn't available. We
*could* do the same - it would mean you couldn't build from source with
JDK1.2 but it would be fully supported.

*Another* solution, which you have already described Christian, is to
write a small adapter that links the ProxyFactory to whatever proxy
implementation we use and you write this as plain text which is compiled
at runtime by something like ASM. Advantage: source compiles under any
JDK; disadvantage: adds a layer of complexity to our source code that
has to be maintained.

I just mention those other two options in passing. I think I actually
favour what you just suggested. Use CGLIB for all JDKs right now. If
getting it to switch between CGLIB and the JDK proxy is going to be at
all difficult then postpone it to a future release.

73,
Bill

Re: [Proxool-developer] JDK independence

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

[Hmm. SourceForge lists seems to have been down. Trying again...]


An ICQ discussion with Bill yesterday ended in these conclusions:

The Timer and ShutdownHook scenarios can be handled without bytecode
manipulation.

For the Timer we will check runtime wether the Timer class is
available or not. If not available we will use our own timing code.
The Timer will only be accessed through reflection so that our source
will compile under JDK 1.2.

The same strategy will be applied to the ShutdownHook except that we
will not offer any alternative implementation for 1.2. We'll simply
document that 1.2 users will have to take care of the shutdown
expilcitly.

The Proxy scenario is a bit more complex. I have evaluated the
following libraries in conjuction with this:

ASM (http://asm.objectweb.org/)
This proved to be a very low level library that requires a good
knowledge of the Java byte code instruction set. It is very small and
fast, but unless anybody wants to dive into the JVM spec I think its
going to be to complex to use.

Javassist (http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/javassist)

Unlike ASM this library offers a very high level api for class
manipulation. It enables you to create and load classes runtime, and
can even compile and add methods to classes from strings containing
source code (!). It's a medium size lib (about 350k). It does not
come with a ready made Proxy replacement, but we can probably roll
our own with a bit of effort.

CGLIB (http://cglib.sourceforge.net/)
This uses ASM as a backend and comes with a ready made replacement
for Proxy. The lib size is (145k). I did a rough benchmark between
CGLIB and the JDK Proxy. CGLIB added a slight overhead compared to
JDK Proxy calls, but it was very tiny. A million method calls to a
simple string getter took about 550 milliseconds using the JDK Proxy,
and about 650 milliseconds using CGLIB. I'll do the CGLIB test with
1.2 as well (the test was performed on 1.4.2) to make sure that the
overheasd is not significantly larger there.

I guess the best solution would be to use a similar approach to that
mentioned above: Use Proxy for 1.3+ and CGLIB for 1.2. The problem
here is that I have not figured out how to make a class implement the
InnvocationHandler *runtime* with CGLIB. This is a simple method call
in Javassist. I'll investigate further...

Another compelling approach is to simply stop using the JDK Proxy and
use the CGLIB Proxy all over. If we go that route we can throw away
the 1.2 source tree today...

I'll do a bit more investigation and keep you updated.

CHR




> On Fri, 2003-09-05 at 14:45, Bill Horsman wrote:
> 
> > Hi,
> > 
> > We're looking at replacing our use of JDK 1.3's proxy
classes with those 
> > from http://asm.objectweb.org. The big benefit we
get, other than 
> > possible performance improvements, is independence from
using JDK 1.3. 
> > Our goal is to continue to support JDK 1.2 for a good while
yet.
> > 
> > The trouble is that we also make some other references to
JDK 1.3+. Namely:
> > 
> > 1) ShutdownHooks. These ensure that Proxool is properly
shutdown when 
> > the JVM dies. It works really well and is much more robust
than using 
> > finalize().
> > 
> > 2) We use a Timer class to collect statistical information.
We can get 
> > round this with either a thread that sleeps for a while and
keeps 
> > checking the time. Or possibly look around for a third
party solution.
> 
> I've been thinking about this. We could use the new proxy to
handle both
> the Timer and the ShutdownHook too. For instance, for the Timer
we write
> and interface that Timer is able to implement and then write our
own
> JDK1.2 implementation. At runtime, we try and load the JDK1.3
Timer and
> if that fails, use our own implementation instead. The proxy
classes are
> used to get JDK1.3's Timer to implement our interface at
runtime. I
> think that would work.
> 
> Advantages: 1) We get to use the (probably) more efficient JDK1.3
> classes if available. 2) Our code compiles with all JDKs.
> 
> Disadvantages: 1) It might be a bit slower (but this doesn't
matter
> because both ShutdownHook and Timer are only constructed at
startup).
> 
> Christian, if you are working on the proxy stuff over the next
few days
> then you might want to think about this).
> 
> Cheers,
> Bill

-- 
__________________________________________________________
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] JDK independence

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

On Fri, 2003-09-05 at 14:45, Bill Horsman wrote:

> Hi,
> 
> We're looking at replacing our use of JDK 1.3's proxy classes with those 
> from http://asm.objectweb.org. The big benefit we get, other than 
> possible performance improvements, is independence from using JDK 1.3. 
> Our goal is to continue to support JDK 1.2 for a good while yet.
> 
> The trouble is that we also make some other references to JDK 1.3+. Namely:
> 
> 1) ShutdownHooks. These ensure that Proxool is properly shutdown when 
> the JVM dies. It works really well and is much more robust than using 
> finalize().
> 
> 2) We use a Timer class to collect statistical information. We can get 
> round this with either a thread that sleeps for a while and keeps 
> checking the time. Or possibly look around for a third party solution.

I've been thinking about this. We could use the new proxy to handle both
the Timer and the ShutdownHook too. For instance, for the Timer we write
and interface that Timer is able to implement and then write our own
JDK1.2 implementation. At runtime, we try and load the JDK1.3 Timer and
if that fails, use our own implementation instead. The proxy classes are
used to get JDK1.3's Timer to implement our interface at runtime. I
think that would work.

Advantages: 1) We get to use the (probably) more efficient JDK1.3
classes if available. 2) Our code compiles with all JDKs.

Disadvantages: 1) It might be a bit slower (but this doesn't matter
because both ShutdownHook and Timer are only constructed at startup).

Christian, if you are working on the proxy stuff over the next few days
then you might want to think about this).

Cheers,
Bill

Re: [Proxool-developer] more than one pool

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

Hi Keith,

On Fri, 5 Sep 2003, Cochran, Keith wrote:

> I'm connecting to two different databases in my application.  I'm getting a
> null pointer exception when trying to connect to the second one, and I'm
> wondering how to do this properly.  Here are my steps:
> 
> 1. Set Class.forName()
> 2. Set properties for first db. (pool name is proxool.first)
> 3. Do a ProxoolFacade.registerConnectionPool() for these properties
> 4. Get a connection (this works fine)

And, presumably, you set the URL too? I guess you do or it wouldn't work.

> 5. set properties for second db (pool name is proxool.second)
> 6. Do a ProxoolFacade.registerConnectionPool() for these new properties
> 7. get a connection (null pointer exception)

I think I need to see your code. Your steps sound reasonable.

What would be _really_ interesting is to know _where_ the
NullPointerException occured ;-) And, even better, a stack trace.

Other things to try:

Swap the pools round. Is it always the one called "proxool.second" or is
it the second one you register?

Trying opening more than one connection on the first pool and check that
it isn't just that your driver won't let you open two connections.

What is your driver, by the way?

Do you have logging setup, or is everything just logging to stdout? It's
not too hard to setup something like Log4J and you'll find it very useful
(there's more information on logging in the user guide on the web site).
At the very least, you should switch on debugging.

Let me know how you get on.

Cheers,
Bill Horsman