| Issue 24: | choosing CGLib versus Javassist | |
| 1 person starred this issue and may be notified of changes. | Back to list |
StubFactory is somewhat brittle. I suggest using a system property such as funcito.codegen.lib to specify the library. Values are 'CGLIB' and 'JAVASSIST' with the former being the default.
Nov 29, 2011
Project Member
#1
kandpwel...@gmail.com
Dec 2, 2011
So can you unpack how this would work in practice? Would the default value be hidden internal to code, or deployed in a resource file? If deployed, are we now deploying in a zip rather than a simple jar, so that user can replace or update the resource file, etc...?
Dec 6, 2011
FYI, "brittle" != defect. Reclassifying. I agree with the premise, but I still want to see your proposal unpacked some more.
Labels:
-Type-Defect Type-Design
Dec 12, 2011
I'm actually very interested in this -- which probably doesn't come thru in my previous comments. So I am raising the priority. I would like to see this resolved before the first "real" release, which I am very unofficially hoping to have before the New Year.
Labels:
-Priority-Medium Priority-High
Dec 12, 2011
Here is one algorithm: - look for a system property called 'funcito.codegen.lib'. If found, use the one specified - Otherwise, search the classpath for both CGLib and Javassist - if only one is present, then clearly: use that one - if no property and both are on the classpath, use CGLib but write a warning message This should scale fairly well if there are 3rd or 4th alternatives in the future.
Dec 12, 2011
Sounds good. Take it. Also, as part of the "choosing the codegen lib" task, I want to be able to test that Javassist will be chosen if cglib is not present. This would require a different classpath for the particular test. I was looking for examples on how to do this, and so far all I could find was the idea of a custom test runner: http://marc.info/?l=jakarta-commons-dev&m=112004597501874&w=2 I don't know how other projects handle testing for multiple version of library compatibility, but we could possibly use the above technique to test some major releases of cglib and javassist. This to me is more important than testing versions of the functional libraries, since the codegen libs seems to be more brittle.
Dec 13, 2011
90% complete. Need to write a warning and possibly some tests. The current unit testing is pretty stout, as system-level predicates are pushed to their own classes, which are mocked. I have verified the behaviour manually, using the command-line and a suite of CLASSPATH settings. I don't know how to automate this (re: your link). I think we should probably have integration tests that are executed from Gradle, rather than JUnit.
Status:
Started
Dec 15, 2011
I just saw this last night and added some code review comments to the changelist.
Dec 16, 2011
adding milestone
Labels:
Milestone-Release0.1
Dec 16, 2011
Review comments have been accepted and incorporated. Also, we write a warning to System.err when there are 2 codegen jars on the classpath but neither is explicitly specified (in which case we default to CgLib).
Status:
CodeComplete
Dec 16, 2011
(No comment was entered for this change.)
Status:
Fixed
|