Richard S. Hall wrote
> Did the reply-to change for our mailing lists?
>
> Before when I would reply to a message it would go to the list, now it
> goes to the sender. Was this a change on the list or a change in my
> email client?
>
Still works for me
Carsten
--
Carsten Ziegeler
Adobe Rese
On 5/2/17 19:41 , Richard S. Hall wrote:
Resending to the mailing list...
On 5/2/17 18:55 , Dirk Hogan wrote:
Hi Richard-
I have a embedded jetty OSGi component that exposes the
conglomeration of
OSGi services to the outside world. Felix would need to set these
service
references in a thread-
Did the reply-to change for our mailing lists?
Before when I would reply to a message it would go to the list, now it
goes to the sender. Was this a change on the list or a change in my
email client?
-> richard
p.s. If you really want to make this a spec discussion vs an
implementation issue, you could bring it up on the
osgi-...@mail.osgi.org mailing list.
On 5/2/17 18:55 , Dirk Hogan wrote:
Hi Richard-
I have a embedded jetty OSGi component that exposes the conglomeration of
OSGi services to the ou
Resending to the mailing list...
On 5/2/17 18:55 , Dirk Hogan wrote:
Hi Richard-
I have a embedded jetty OSGi component that exposes the conglomeration of
OSGi services to the outside world. Felix would need to set these service
references in a thread-safe way. You appear to be suggesting that F
Hi Richard-
I have a embedded jetty OSGi component that exposes the conglomeration of
OSGi services to the outside world. Felix would need to set these service
references in a thread-safe way. You appear to be suggesting that Felix can
be only consumed by the Felix threads themselves, as only that
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5630:
-
Affects Version/s: (was: org.apache.felix.dependencymanager-r9)
org.apac
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993881#comment-15993881
]
Pierre De Rop commented on FELIX-5630:
--
I committed a candidate fix in revision 17935
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993876#comment-15993876
]
Pierre De Rop commented on FELIX-5630:
--
Added test case for this issue in revision 17
Dirk,
Allow I'm not well versed on the details of JMM. I think this boils down
to typical OSGi component code will be going through the hidden barriers
in the the framework when they try to retrieve and access the service
objects. You appear to be concocting a situation where you have threads
Hi Neil-
OK - now we are getting somewhere.
You need to dig a bit deeper to see what establishes a happens-before
relationship. For within a single thread, it is the Program Order: the
underlying virtual machine cannot allow the visibility of memory effects
which contradict the sequence of instruc
I think I get what Dirk is saying, and although I disagree with some of his
analysis there is arguably a gap in the DS specification that makes this
unclear. I hope somebody can point at the vital sentence I have missed, but
here is my analysis:
The JLS defines happens-before thus: "Two actions
Hi David-
I am asserting that unless the @Reference is volatile, regardless of
whether it is STATIC or DYNAMIC, a data race is present.
The JMM states synchronization barriers on DISTINCT monitors have no memory
effects for the references read/written within the synchronization blocks.
That is sta
I don’t understand your example or I don’t understand how your example relates
to an osgi or ds problem.
I think you are proposing that the DS component is an http server and starts
threads etc. If so, it’s that components responsibility to make sure its’
internal operations are thread safe, a
[
https://issues.apache.org/jira/browse/FELIX-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5632.
-
Resolution: Fixed
Done in rev 1793566
> Implement equals and hashCode for HttpSessionWrap
Carsten Ziegeler created FELIX-5632:
---
Summary: Implement equals and hashCode for HttpSessionWrapper
Key: FELIX-5632
URL: https://issues.apache.org/jira/browse/FELIX-5632
Project: Felix
Issu
Hi Raymond-
Assume Felix does it's thing: sets all @References, activates all
components, publishes all services. It has resolved all dependencies, and
set references accordingly.
Thus, in the example above, myOSGiComponent has its @Reference to
SomeOtherOSGiService resolved - Felix has set this r
On Tue, May 2, 2017 at 1:18 PM, Raymond Auge
wrote:
>
>
> On Tue, May 2, 2017 at 1:14 PM, Raymond Auge
> wrote:
>
>>
>> On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan
>> wrote:
>>
>>> But no similar guarantee applies when another thread hits the
>>> component,
>>>
>>
>> I believe the discussion bo
On Tue, May 2, 2017 at 1:14 PM, Raymond Auge
wrote:
>
> On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan
> wrote:
>
>> But no similar guarantee applies when another thread hits the
>> component,
>>
>
> I believe the discussion boils down to why you believe the above is
> possible?
>
> If SCR has not
On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan
wrote:
> But no similar guarantee applies when another thread hits the
> component,
>
I believe the discussion boils down to why you believe the above is
possible?
If SCR has not yet made the component available to other threads (which, to
my knowledg
Hi Neil-
I agree that, upon publication, the service has been activated, and thus
all references are visible to the thread which performed the publication.
But the java memory model explicitly distinguishes between:
---Program order: which guarantees that the underlying virtual machine must
ensure
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992884#comment-15992884
]
Pierre De Rop commented on FELIX-5630:
--
oops, no, the issue is probably a regression
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992870#comment-15992870
]
Pierre De Rop commented on FELIX-5630:
--
Thanks for reporting Jeroen;
It looks like y
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop reassigned FELIX-5630:
Assignee: Pierre De Rop
> NullObject is created for a required dependency if the component
[
https://issues.apache.org/jira/browse/FELIX-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5631.
Resolution: Fixed
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M
Guillaume Nodet created FELIX-5631:
--
Summary: [gogo][runtime] The parser indicates wrong repair string
when parsing heredocs
Key: FELIX-5631
URL: https://issues.apache.org/jira/browse/FELIX-5631
Proj
[
https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen Daanen updated FELIX-5630:
-
Priority: Minor (was: Major)
> NullObject is created for a required dependency if the component i
Jeroen Daanen created FELIX-5630:
Summary: NullObject is created for a required dependency if the
component is removed and added again to the dependency manager
Key: FELIX-5630
URL: https://issues.apache.org/jira/
28 matches
Mail list logo
