Hi

We're pretty much at the situation of what I commented after your finding.

If the war is updated a refresh is needed. Most likely there is a dynamic
import on the weld bundle. So in that case there are two possible solutions.

A) always refresh the weld bundle in case of an update of the war. That
usually should only happen in rare cases.

B) check how the tracking is solved right now and check if a bundle tracker
solved the issue. Maybe some other sort of service tracker might also be
needed. But the weld bundle should refrain from dynamically loading classes
from the war.

Regards, Achim

sent from mobile device

Am 02.06.2017 8:00 nachm. schrieb "Pavel" <[email protected]>:

> Hi Achim
>
> Thank you for your answer. Weld developers asked their questions
> based on the last comments - where we found steps to reproduce the bug.
>
> See from this point
>
> https://ops4j1.jira.com/browse/PAXWEB-760?focusedCommentId=35942&page=
> com.atlassian.jira.plugin.system.issuetabpanels%
> 3Acomment-tabpanel#comment-35942
>
> What can you say about weld listeners? Can this be the problem?
>
> Maybe we should wait until you can get access to desktop PC?
> What will you say? I am sure it is not problem to wait.
>
> Best regards, Pavel
>
> пятница, 2 июня 2017 г., 20:49:05 UTC+3 пользователь Achim Nierbeck
> написал:
>>
>> Hi
>>
>> First of all right now I only have a mobile device so my explanations
>> might be a bit brief.
>>
>> The initial description of the bug doesn't say anything of a restart.
>> Therefore I'm not sure we're actually tall about the same issue. Maybe
>> similar but from your description this seems to be different.
>>
>> Any way regarding your questions below.
>> 1. A bundle update does the following.
>> The old bundle is stopped and replaced by the new bundle. BUT there is no
>> refresh or better rewiring. This means all existing references to the old
>> bundle, for example references to classes are not updated. This can only be
>> solved by a bundle update followed by a refresh on  all bundles referencing
>> this one.
>>
>> 2. I'm not sure I understand the context. But if you are talking of
>> updating another bundle which is indirectly referenced by the web
>> application bundle which is part of the session. No, reason see above.
>>
>> 3. Again I do not fully understand the context. But taken from the first
>> question, an update of another bundle. No, again if there is no refresh
>> there is no reason.
>>
>> Regards, Achim
>>
>> Pavel <[email protected]> schrieb am Do. 1. Juni 2017 um 15:32:
>>
>>> Hi all
>>>
>>> The post is about https://ops4j1.jira.com/browse/PAXWEB-760 bug. I had
>>> an idea
>>> that maybe Weld developers could give any hints to fix this bug and I
>>> asked
>>> them what they think about this bug.
>>>
>>> That is what they wrote:
>>> "It looks like the Weld container is restarted but the Weld listener is
>>> reused and thus is referencing the previous container which is cleaned
>>> up and shutdown."
>>>
>>> Besides they asked the following questions:
>>> 1) What does Bundle.update actually do?
>>> 2) Is the HTTP session destroyed?
>>> 3) Are the HttpSessionListener instances thrown away?
>>>
>>> If someone of Pax-Web developers give me answer and I resend
>>> them maybe Weld developers could say something else.
>>>
>>> Best regards, Pavel
>>>
>>> --
>>> --
>>> ------------------
>>> OPS4J - http://www.ops4j.org - [email protected]
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OPS4J" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - [email protected]
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
------------------
OPS4J - http://www.ops4j.org - [email protected]

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to