So the thing is: I have a jar in domains/domain1/lib folder, which
contains the filter.
When I execute the redeploy command the destroy is called, but the class
will remain the same, it won't be unloaded, and next time the filter is
initializing it can see some previous static variables around the
filter, which makes things wrong. Probably I only need to enhance my
destroy to release those resources a bit better.
Sorry for the noise.
Thanks,
Peter
2010-10-05 00:16 keltezéssel, Major Péter írta:
> Yes, the filter is declared in the web.xml. Let me investigate on this a
> bit more, and I'll be back with the results.
> //I didn't saw exception in server.log
>
> Thanks,
> Peter
>
>
> 2010-10-04 23:56 keltezéssel, Shing Wai Chan írta:
>> I don't recall any change in this area from 3.0.1 to 3.1.
>> Do you declare the filter in web.xml? Do you see any exception in the
>> server.log?
>> Shing Wai Chan
>>
>>
>> On 10/4/2010 2:40 PM, Major Péter wrote:
>>> Yes, the same command, but with GF 3.0.1.
>>> Maybe the tricky part is that my Filter is not inside the EAR, but
>>> resides in the domains/domain1/lib directory (and tries to load new
>>> classes for shutdownmgmt)?
>>>
>>> Thanks,
>>> Peter
>>>
>>> 2010-10-04 23:34 keltezéssel, Shing Wai Chan írta:
>>>> In 3.1, I do see Filter.destroy() is called when I run asadmin deploy
>>>> --force=true ...
>>>> Do you use the above command to force redeploy?
>>>> Shing Wai Chan
>>>>
>>>>
>>>> On 10/4/2010 2:16 PM, Major Péter wrote:
>>>>> Hi,
>>>>>
>>>>> I'm guessing this currently, but it looks like, that GlassFish does not
>>>>> destroys the applications filters when force redeploying the
>>>>> application. Sadly this means for me, that the application is not
>>>>> releasing it's resources, and thus it fails while it tries to recollect
>>>>> them.
>>>>> Is this the expected behavior? Can someone confirm this?
>>>>>
>>>>> Thanks,
>>>>> Peter