You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/01/04 05:50:03 UTC
Use of sun classes
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.
That's it. So should we remove these?
-dain
Re: Use of sun classes
Posted by Karan Malhi <ka...@gmail.com>.
Thanks Jacek.
On 1/7/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>
> On 1/7/07, Karan Malhi <ka...@gmail.com> wrote:
> > 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.
>
> The update should've been sent. I don't know why it didn't get through.
>
> > 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.
>
> If JIRA had worked well that day, we would've known you updated the
> issue and someone would take care of the patch of yours. In such a
> case when no notification is sent, a friendly reminder to the mailing
> list is enough. Thanks!
>
> Cross your fingers to get it committed tonight ;-)
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karan Malhi
Re: Use of sun classes
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/7/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> Cross your fingers to get it committed tonight ;-)
Done.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Use of sun classes
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/7/07, Karan Malhi <ka...@gmail.com> wrote:
> 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.
The update should've been sent. I don't know why it didn't get through.
> 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.
If JIRA had worked well that day, we would've known you updated the
issue and someone would take care of the patch of yours. In such a
case when no notification is sent, a friendly reminder to the mailing
list is enough. Thanks!
Cross your fingers to get it committed tonight ;-)
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Use of sun classes
Posted by Karan Malhi <ka...@gmail.com>.
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 <da...@iq80.com> 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
Re: Use of sun classes
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Use of sun classes
Posted by David Blevins <da...@visi.com>.
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.
>> 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.
-David
Re: Use of sun classes
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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.
>
> That's it. So should we remove these?
Absolutely. OPENEJB-433
Regards,
Alan