You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2008/01/12 00:45:23 UTC
Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Hi,
I've been trying to fix the issue OPENEJB-746 Command line tool
Deploy/Undeploy asymmetry [1] for the past *couple* days and can't
seem to find a solution for it. Once a file of a module's loaded in a
classloader (via xbean-finder's ResourceFinder) it's locked and the
module itself can't be deleted. A file can be deleted via File.delete
iff no classloaders hold it or the files within (if it's a jar file).
Could anyone lend me a hand with it? I'm stuck.
[1] https://issues.apache.org/jira/browse/OPENEJB-746
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 12, 2008 1:06 AM, Dain Sundstrom <da...@iq80.com> wrote:
> I start the server and use a profiler to see how many class loaders I
> have. Then I deploy the app, and note new class loaders. Finally, I
> undeploy the application and see which of the new class loaders have
> not been garbage collected. Now you use your profiler to see what
> is holding on to the class loader (the GC roots that have a hard
> reference chain to the class loader).
>
> I strongly suggest you use YourKit to profile the app. You can get a
> free license as an Apache committer, but I'm not sure how. If you
> are a codehaus committer, the YourKit license key is xircles.
>
> Alternatively, I can take a look at this next week.
No, you don't have to, but I'll keep that in mind, though. Your
suggestions made me confident I can do it myself. Although I've never
used YourKit before I'd like to see how it helps. Thanks!
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 12, 2008 1:06 AM, Dain Sundstrom <da...@iq80.com> wrote:
> I strongly suggest you use YourKit to profile the app. You can get a
> free license as an Apache committer, but I'm not sure how. If you
> are a codehaus committer, the YourKit license key is xircles.
Got YourKit installed with the license from xircles. Thanks again!
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 14, 2008 11:02 PM, Alexander Saint Croix
<sa...@gmail.com> wrote:
> I can confirm that Mapped Superclasses *do* work in OpenJPA. I have a
> mapped superclass at the base of my entity library and have had good success
> with it.
That doesn't make any good as it turns out I broke it after
incorporating my changes. I was completely clueless yesterday as to
how to proceed with the issue and was glad Dain stepped forward and
took care of it. I'm looking forward to seeing his changes for the
issue and learning how he approach it. I think there were too many
places with our temporary classloaders.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Alexander Saint Croix <sa...@gmail.com>.
Jacek,
I can confirm that Mapped Superclasses *do* work in OpenJPA. I have a
mapped superclass at the base of my entity library and have had good success
with it.
HTH,
--
Alex
On Jan 14, 2008 6:52 AM, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>
> > Alternatively, I can take a look at this next week.
>
> Okey, I had a nice and pleasant weekend trying to fix it, but even
> though module jars can be deleted with the patch I submitted to
> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>
> Dain, could you take a look into it and see why I'm stuck with the
> issue you described long time ago - Do mapped superclasses work at all
> in OpenJPA? (
> http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html
> ).
> I'm unable to fix it myself.
>
> https://issues.apache.org/jira/browse/OPENEJB-746
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by David Blevins <da...@visi.com>.
On Jan 17, 2008, at 7:04 PM, Dain Sundstrom wrote:
> I also cleaned up the code that creates the application module id so
> we always get a canonical (absolute) file path (we were getting
> relative paths).
FYI, you're terminology is shifted one word to the left :) What you
called relative is absolute, what you called absolute is canonical.
/Users/dblevins/work/../Library/Preferences (absolute, not conical)
/Users/dblevins/Library/Preferences (absolute and conical)
dblevins/Library/Preferences (relative)
Anyway, very good changes :)
-David
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 18, 2008 4:04 AM, Dain Sundstrom <da...@iq80.com> wrote:
> I hope I didn't step over any uncommitted work you have.
Absolutely not and am glad you fixed it as it's always a pleasure to
read your changes.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
I did a bit more work on the cli deploy and undeploy commands to fix
some things I found frustrating when checkin for memory leaks.
In deploy, I check if the file needs to be unpacked (e.g., ear, war
and rar files) and if so, I unpack it into the server app directory.
This avoids the extra copy file step. I also cleaned up the code that
creates the application module id so we always get a canonical
(absolute) file path (we were getting relative paths).
In undeploy, I added support for "openejb undeploy $OPENEJB_HOME/apps/
myapp". This makes is easy to undeploy from the command line without
having to lookup the module id.
I hope I didn't step over any uncommitted work you have.
-dain
On Jan 17, 2008, at 12:42 AM, Jacek Laskowski wrote:
> On Jan 17, 2008 5:34 AM, David Blevins <da...@visi.com> wrote:
>> Did the part of the fix that deletes the jar (and any associated
>> unpacked directory) get added already?
>
> I'm going to give it a shot again after Dain's changes (and provided
> they work on ms windows).
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 17, 2008 5:34 AM, David Blevins <da...@visi.com> wrote:
> Did the part of the fix that deletes the jar (and any associated
> unpacked directory) get added already?
I'm going to give it a shot again after Dain's changes (and provided
they work on ms windows).
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
I just fixed the class loader leak bug which stops files from being
deleted. After a quick check we still aren't deleting the jars.
-dain
On Jan 16, 2008, at 8:34 PM, David Blevins wrote:
> Did the part of the fix that deletes the jar (and any associated
> unpacked directory) get added already?
>
> -David
>
> On Jan 16, 2008, at 6:28 PM, Dain Sundstrom wrote:
>
>> It was a huge PITA, but I think I have fixed this. There were two
>> leaks in JPA. The first was caused by registering a class file
>> transformer, but never unregister it. The second is caused by a
>> class loader cache in OpenJPA, and which must be cleared directly
>> when the app is destroyed (I wish they used weak references).
>>
>> I only verified the fix by inspecting the heap dump to assure that
>> after the application is undeployed we return to having only one
>> class loader in the vm. If you have time, can please verify on
>> Windows and if this is fixed close the JIRA issue.
>>
>> Thanks,
>>
>> -dain
>>
>> On Jan 16, 2008, at 2:32 PM, Dain Sundstrom wrote:
>>
>>> Finally, got time (energy) to look at this.
>>>
>>> I think (and I could be wrong) the bulk of this patch is to
>>> convert OpenEJB to the XBean JarFileClassLoader and to explicitly
>>> close all JarFiles and class loader resource input streams.
>>> Unfortunately, switching to the JarFileClassLoader only fixes the
>>> problem when OpenEJB is run standalone. When we are embedded in
>>> Tomcat or JUnit, we don't control the class loader. This means
>>> that in these other modes we can't relying on the explicit close
>>> method of the JarFileClassLoader, and instead we must make sure
>>> that our class loaders are garbage collected when the application
>>> is undeployed. This is a lot more difficult, but is still
>>> practical and something that was working OpenEJB 3....
>>>
>>> Somewhere in the last few months we seem to have regressed when it
>>> comes to the GCability of our application class loader.
>>> Specifically, JPA is holding on to the class loader again. I am
>>> working on a patch to clear this up, and I hope to be able to
>>> create a test case for the GCability of our class loader.
>>>
>>>
>>> As for this patch, I don't think we should apply it. I'd prefer
>>> that we don't switch standalone to JarFileClassLoader as it will
>>> mask the problems that will pop up in the other modes. I would
>>> also prefer that we don't add the explicit close of the JarFile
>>> and class loader resource stream as it adds extra unneeded
>>> complexity to this code since they will be closed automatically
>>> when GCed from the stack (these are method local variables).
>>>
>>>
>>> A few notes on the patches:
>>> - In the future, please don't mix reformatting with new code in
>>> patch files, as it makes it difficult to review the new code
>>> - OpenEJB doesn't use xbean-spring
>>> - TemporaryClassLoader has very different behavior then
>>> JarFileClassLoader and one shouldn't be swapped for the other
>>> without lots of thought (this is possibly the cause of the CMP2JPA
>>> problems)
>>>
>>> This is just my opinion, and am curious what others think about
>>> this.
>>>
>>> -dain
>>>
>>> On Jan 14, 2008, at 12:38 PM, Dain Sundstrom wrote:
>>>
>>>> Looking...
>>>>
>>>> -dain
>>>>
>>>> On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
>>>>
>>>>> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>>>>>
>>>>>> Alternatively, I can take a look at this next week.
>>>>>
>>>>> Okey, I had a nice and pleasant weekend trying to fix it, but even
>>>>> though module jars can be deleted with the patch I submitted to
>>>>> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>>>>>
>>>>> Dain, could you take a look into it and see why I'm stuck with the
>>>>> issue you described long time ago - Do mapped superclasses work
>>>>> at all
>>>>> in OpenJPA? (http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html
>>>>> ).
>>>>> I'm unable to fix it myself.
>>>>>
>>>>> https://issues.apache.org/jira/browse/OPENEJB-746
>>>>>
>>>>> Jacek
>>>>>
>>>>> --
>>>>> Jacek Laskowski
>>>>> http://www.JacekLaskowski.pl
>>>>
>>>
>>
>>
>
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by David Blevins <da...@visi.com>.
Did the part of the fix that deletes the jar (and any associated
unpacked directory) get added already?
-David
On Jan 16, 2008, at 6:28 PM, Dain Sundstrom wrote:
> It was a huge PITA, but I think I have fixed this. There were two
> leaks in JPA. The first was caused by registering a class file
> transformer, but never unregister it. The second is caused by a
> class loader cache in OpenJPA, and which must be cleared directly
> when the app is destroyed (I wish they used weak references).
>
> I only verified the fix by inspecting the heap dump to assure that
> after the application is undeployed we return to having only one
> class loader in the vm. If you have time, can please verify on
> Windows and if this is fixed close the JIRA issue.
>
> Thanks,
>
> -dain
>
> On Jan 16, 2008, at 2:32 PM, Dain Sundstrom wrote:
>
>> Finally, got time (energy) to look at this.
>>
>> I think (and I could be wrong) the bulk of this patch is to convert
>> OpenEJB to the XBean JarFileClassLoader and to explicitly close
>> all JarFiles and class loader resource input streams.
>> Unfortunately, switching to the JarFileClassLoader only fixes the
>> problem when OpenEJB is run standalone. When we are embedded in
>> Tomcat or JUnit, we don't control the class loader. This means
>> that in these other modes we can't relying on the explicit close
>> method of the JarFileClassLoader, and instead we must make sure
>> that our class loaders are garbage collected when the application
>> is undeployed. This is a lot more difficult, but is still practical
>> and something that was working OpenEJB 3....
>>
>> Somewhere in the last few months we seem to have regressed when it
>> comes to the GCability of our application class loader.
>> Specifically, JPA is holding on to the class loader again. I am
>> working on a patch to clear this up, and I hope to be able to
>> create a test case for the GCability of our class loader.
>>
>>
>> As for this patch, I don't think we should apply it. I'd prefer
>> that we don't switch standalone to JarFileClassLoader as it will
>> mask the problems that will pop up in the other modes. I would
>> also prefer that we don't add the explicit close of the JarFile and
>> class loader resource stream as it adds extra unneeded complexity
>> to this code since they will be closed automatically when GCed from
>> the stack (these are method local variables).
>>
>>
>> A few notes on the patches:
>> - In the future, please don't mix reformatting with new code in
>> patch files, as it makes it difficult to review the new code
>> - OpenEJB doesn't use xbean-spring
>> - TemporaryClassLoader has very different behavior then
>> JarFileClassLoader and one shouldn't be swapped for the other
>> without lots of thought (this is possibly the cause of the CMP2JPA
>> problems)
>>
>> This is just my opinion, and am curious what others think about this.
>>
>> -dain
>>
>> On Jan 14, 2008, at 12:38 PM, Dain Sundstrom wrote:
>>
>>> Looking...
>>>
>>> -dain
>>>
>>> On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
>>>
>>>> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>>>>
>>>>> Alternatively, I can take a look at this next week.
>>>>
>>>> Okey, I had a nice and pleasant weekend trying to fix it, but even
>>>> though module jars can be deleted with the patch I submitted to
>>>> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>>>>
>>>> Dain, could you take a look into it and see why I'm stuck with the
>>>> issue you described long time ago - Do mapped superclasses work
>>>> at all
>>>> in OpenJPA? (http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html
>>>> ).
>>>> I'm unable to fix it myself.
>>>>
>>>> https://issues.apache.org/jira/browse/OPENEJB-746
>>>>
>>>> Jacek
>>>>
>>>> --
>>>> Jacek Laskowski
>>>> http://www.JacekLaskowski.pl
>>>
>>
>
>
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
It was a huge PITA, but I think I have fixed this. There were two
leaks in JPA. The first was caused by registering a class file
transformer, but never unregister it. The second is caused by a class
loader cache in OpenJPA, and which must be cleared directly when the
app is destroyed (I wish they used weak references).
I only verified the fix by inspecting the heap dump to assure that
after the application is undeployed we return to having only one class
loader in the vm. If you have time, can please verify on Windows and
if this is fixed close the JIRA issue.
Thanks,
-dain
On Jan 16, 2008, at 2:32 PM, Dain Sundstrom wrote:
> Finally, got time (energy) to look at this.
>
> I think (and I could be wrong) the bulk of this patch is to convert
> OpenEJB to the XBean JarFileClassLoader and to explicitly close all
> JarFiles and class loader resource input streams. Unfortunately,
> switching to the JarFileClassLoader only fixes the problem when
> OpenEJB is run standalone. When we are embedded in Tomcat or JUnit,
> we don't control the class loader. This means that in these other
> modes we can't relying on the explicit close method of the
> JarFileClassLoader, and instead we must make sure that our class
> loaders are garbage collected when the application is undeployed.
> This is a lot more difficult, but is still practical and something
> that was working OpenEJB 3....
>
> Somewhere in the last few months we seem to have regressed when it
> comes to the GCability of our application class loader.
> Specifically, JPA is holding on to the class loader again. I am
> working on a patch to clear this up, and I hope to be able to create
> a test case for the GCability of our class loader.
>
>
> As for this patch, I don't think we should apply it. I'd prefer
> that we don't switch standalone to JarFileClassLoader as it will
> mask the problems that will pop up in the other modes. I would also
> prefer that we don't add the explicit close of the JarFile and class
> loader resource stream as it adds extra unneeded complexity to this
> code since they will be closed automatically when GCed from the
> stack (these are method local variables).
>
>
> A few notes on the patches:
> - In the future, please don't mix reformatting with new code in
> patch files, as it makes it difficult to review the new code
> - OpenEJB doesn't use xbean-spring
> - TemporaryClassLoader has very different behavior then
> JarFileClassLoader and one shouldn't be swapped for the other
> without lots of thought (this is possibly the cause of the CMP2JPA
> problems)
>
> This is just my opinion, and am curious what others think about this.
>
> -dain
>
> On Jan 14, 2008, at 12:38 PM, Dain Sundstrom wrote:
>
>> Looking...
>>
>> -dain
>>
>> On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
>>
>>> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>>>
>>>> Alternatively, I can take a look at this next week.
>>>
>>> Okey, I had a nice and pleasant weekend trying to fix it, but even
>>> though module jars can be deleted with the patch I submitted to
>>> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>>>
>>> Dain, could you take a look into it and see why I'm stuck with the
>>> issue you described long time ago - Do mapped superclasses work at
>>> all
>>> in OpenJPA? (http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html
>>> ).
>>> I'm unable to fix it myself.
>>>
>>> https://issues.apache.org/jira/browse/OPENEJB-746
>>>
>>> Jacek
>>>
>>> --
>>> Jacek Laskowski
>>> http://www.JacekLaskowski.pl
>>
>
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
Finally, got time (energy) to look at this.
I think (and I could be wrong) the bulk of this patch is to convert
OpenEJB to the XBean JarFileClassLoader and to explicitly close all
JarFiles and class loader resource input streams. Unfortunately,
switching to the JarFileClassLoader only fixes the problem when
OpenEJB is run standalone. When we are embedded in Tomcat or JUnit,
we don't control the class loader. This means that in these other
modes we can't relying on the explicit close method of the
JarFileClassLoader, and instead we must make sure that our class
loaders are garbage collected when the application is undeployed. This
is a lot more difficult, but is still practical and something that was
working OpenEJB 3....
Somewhere in the last few months we seem to have regressed when it
comes to the GCability of our application class loader. Specifically,
JPA is holding on to the class loader again. I am working on a patch
to clear this up, and I hope to be able to create a test case for the
GCability of our class loader.
As for this patch, I don't think we should apply it. I'd prefer that
we don't switch standalone to JarFileClassLoader as it will mask the
problems that will pop up in the other modes. I would also prefer
that we don't add the explicit close of the JarFile and class loader
resource stream as it adds extra unneeded complexity to this code
since they will be closed automatically when GCed from the stack
(these are method local variables).
A few notes on the patches:
- In the future, please don't mix reformatting with new code in patch
files, as it makes it difficult to review the new code
- OpenEJB doesn't use xbean-spring
- TemporaryClassLoader has very different behavior then
JarFileClassLoader and one shouldn't be swapped for the other without
lots of thought (this is possibly the cause of the CMP2JPA problems)
This is just my opinion, and am curious what others think about this.
-dain
On Jan 14, 2008, at 12:38 PM, Dain Sundstrom wrote:
> Looking...
>
> -dain
>
> On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
>
>> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>>
>>> Alternatively, I can take a look at this next week.
>>
>> Okey, I had a nice and pleasant weekend trying to fix it, but even
>> though module jars can be deleted with the patch I submitted to
>> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>>
>> Dain, could you take a look into it and see why I'm stuck with the
>> issue you described long time ago - Do mapped superclasses work at
>> all
>> in OpenJPA? (http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html
>> ).
>> I'm unable to fix it myself.
>>
>> https://issues.apache.org/jira/browse/OPENEJB-746
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> http://www.JacekLaskowski.pl
>
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Jan 14, 2008 9:38 PM, Dain Sundstrom <da...@iq80.com> wrote:
> Looking...
Many, many thanks. I'd appreciate if you looked at my patch, but don't
want to give you too much hassle ;-)
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
Looking...
-dain
On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
> On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
>
>> Alternatively, I can take a look at this next week.
>
> Okey, I had a nice and pleasant weekend trying to fix it, but even
> though module jars can be deleted with the patch I submitted to
> OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
>
> Dain, could you take a look into it and see why I'm stuck with the
> issue you described long time ago - Do mapped superclasses work at all
> in OpenJPA? (http://www.mail-archive.com/open-jpa-
> dev@incubator.apache.org/msg02045.html).
> I'm unable to fix it myself.
>
> https://issues.apache.org/jira/browse/OPENEJB-746
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/12/08, Dain Sundstrom <da...@iq80.com> wrote:
> Alternatively, I can take a look at this next week.
Okey, I had a nice and pleasant weekend trying to fix it, but even
though module jars can be deleted with the patch I submitted to
OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
Dain, could you take a look into it and see why I'm stuck with the
issue you described long time ago - Do mapped superclasses work at all
in OpenJPA? (http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02045.html).
I'm unable to fix it myself.
https://issues.apache.org/jira/browse/OPENEJB-746
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Re OPENEJB-746 Command line tool Deploy/Undeploy asymmetry
Posted by Dain Sundstrom <da...@iq80.com>.
Here is how I fix this type of problem.
I start the server and use a profiler to see how many class loaders I
have. Then I deploy the app, and note new class loaders. Finally, I
undeploy the application and see which of the new class loaders have
not been garbage collected. Now you use your profiler to see what
is holding on to the class loader (the GC roots that have a hard
reference chain to the class loader).
I strongly suggest you use YourKit to profile the app. You can get a
free license as an Apache committer, but I'm not sure how. If you
are a codehaus committer, the YourKit license key is xircles.
Alternatively, I can take a look at this next week.
-dain
On Jan 11, 2008, at 3:45 PM, Jacek Laskowski wrote:
> Hi,
>
> I've been trying to fix the issue OPENEJB-746 Command line tool
> Deploy/Undeploy asymmetry [1] for the past *couple* days and can't
> seem to find a solution for it. Once a file of a module's loaded in a
> classloader (via xbean-finder's ResourceFinder) it's locked and the
> module itself can't be deleted. A file can be deleted via File.delete
> iff no classloaders hold it or the files within (if it's a jar file).
> Could anyone lend me a hand with it? I'm stuck.
>
> [1] https://issues.apache.org/jira/browse/OPENEJB-746
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl