On Jan 3, 2007, at 11:35 PM, David Blevins wrote:
On Jan 3, 2007, at 10:30 PM, Alan D. Cabrera wrote:
On Jan 3, 2007, at 8:50 PM, Dain Sundstrom wrote:
In the process of hacking on the java agent code the other day, I
ran into a few places where we are directly referring to sun.* or
com.sun.* classes. I removed the user of
com.sun.naming.internal.ResourceManager in the IvmContext but we
still have a few places where we are using sun classes. Should
it be one of our goals to not have hard references to sun classes?
Here are the places I know that we are using sun classes:
JarUtils uses suntools.jar.Main to add an entry to an existing
jar. This could be replaced by creating a new temp jar with
JarOutputStream copying all the data from the existing jar and
adding the one new entry. Then you swap the two files.
BasicURLClassPath, SystemClassPath and TomcatClassPath directly
reference sun.misc.URLClassPath. This reference is obtained
using reflection and set accessible, so with a bit more
reflection we should be able to remove the reference.
I wonder if suntools.jar.Main doesn't do that already. Anyone
know? If they have some secret ninja way to avoid the tmp file
that'd be great. If not, sure let's just do the tmp file thing
ourselves.
IIRC the sun.tools classes are only in a JDK so if we remove this our
code will run on a plain old JRE. I think that would be worth making
the change even with an additional temp file.
That's it. So should we remove these?
Absolutely. OPENEJB-433
Agreed. Alan, I split your jira into two tasks. See OPENEJB-434.
Figured they could be done independently.
BTW, I'm not planing on taking this on, and may be a good set of
tasks for someone to get involved.
-dain
