I did add a patch for it. JIRA did not send an email after i updated this
issue. Is this how JIRA is supposed to work? I thought JIRA would send an
email after an issue was updated.
Secondly, do i have to send a notification after I submit a patch so that
someone could review it, or does someone always reviews and commits patches
as they are added to JIRA.

On 1/4/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

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




--
Karan Malhi

Reply via email to