[VOTE] Using ThreadLocal vs passing the Context around for all method calls?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
Hi,

In the new xwiki architecture we need to take a call for passing the  
request, response and session around (what is currently called the  
XWikiContext). We have 2 solutions:
1) we pass it around for all method calls as it's currently done
2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html 
.

The advantage of solution 2) is that any component in the new  
architecture can decide to have the Container component injected (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/)
  and thus be allowed to access the request, response and session  
objects without having all its method add a Container object passed to  
it.

The downside of solution 2) is simply that we associate Unit Of Work  
with Threads. But since we use a Servlet model and since I don't see  
any foreseeable future where we would want to use several threads for  
the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination 
  for some explanation on this.

So right now and even though ThreadLocal sound a little bit "hackish",  
I think this is still my preference as it'll save us from having to  
pass Container objects everywhere.

Since this is an important architecture decision I wanted to have a  
vote for it.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

rssh
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
> Hi,
>

Sorry, may be this is not my question, but: I can imagine situation, where
ThreadLocal approach will fail:  it's when we do asynchronics call to some
external entity with callback. In such case callback will not receive context in
ThreadLocal.  And it is possible (and very common approach) to do this from
groovy scripts (as groovy has closures).



--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
Hi Ruslan,

On Apr 12, 2008, at 12:02 PM, rssh wrote:

> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>> Hi,
>>
>
> Sorry, may be this is not my question, but: I can imagine situation,  
> where
> ThreadLocal approach will fail:  it's when we do asynchronics call  
> to some
> external entity with callback. In such case callback will not  
> receive context in
> ThreadLocal.  And it is possible (and very common approach) to do  
> this from
> groovy scripts (as groovy has closures).

I don't understand what would not work... Would you mind giving some  
details and use cases?

Thanks
-Vincent



_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Pascal Voitot
In reply to this post by rssh
Even if I can't say I'm an expert of XWiki yet, let me give my point of
view...
The ThreadLocal is interesting but can bring lots of design constraints
also...
Moreover, I think the stateless approach would be an insurance for future
evolutions and passing the context seems better for that...
For example, I have been thinking about an XWiki engine using service
oriented approach... without the Servlet model... A raw XWiki service
provider without knowledge of its communication and presentation layers...
Like this, it would be easy to imagine P2P, balancing, grid computing etc...
To my mind, the component model goes in this way...

ThreadLocal and stateless approach may be compliant but I'm sure about this
:)

Pascal


On 4/12/08, rssh <[hidden email]> wrote:

>
> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
> > Hi,
> >
>
> Sorry, may be this is not my question, but: I can imagine situation, where
> ThreadLocal approach will fail:  it's when we do asynchronics call to some
> external entity with callback. In such case callback will not receive
> context in
> ThreadLocal.  And it is possible (and very common approach) to do this
> from
> groovy scripts (as groovy has closures).
>
>
>
> --
> Ruslan Shevchenko
> GradSoft. http://www.gradsoft.ua
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Artem Melentyev-3
In reply to this post by vmassol
+1 to 2).
It is very awkward to pass context in Every method.

We can use InheritableThreadLocal to provide the context in child
threads if needed.

Vincent Massol wrote:

> Hi,
>
> In the new xwiki architecture we need to take a call for passing the  
> request, response and session around (what is currently called the  
> XWikiContext). We have 2 solutions:
> 1) we pass it around for all method calls as it's currently done
> 2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html 
> .
>
> The advantage of solution 2) is that any component in the new  
> architecture can decide to have the Container component injected (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/)
>   and thus be allowed to access the request, response and session  
> objects without having all its method add a Container object passed to  
> it.
>
> The downside of solution 2) is simply that we associate Unit Of Work  
> with Threads. But since we use a Servlet model and since I don't see  
> any foreseeable future where we would want to use several threads for  
> the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination 
>   for some explanation on this.
>
> So right now and even though ThreadLocal sound a little bit "hackish",  
> I think this is still my preference as it'll save us from having to  
> pass Container objects everywhere.
>
> Since this is an important architecture decision I wanted to have a  
> vote for it.

--
   Artem Melentyev
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

rssh
In reply to this post by vmassol
On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote

> Hi Ruslan,
>
> On Apr 12, 2008, at 12:02 PM, rssh wrote:
>
> > On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
> >> Hi,
> >>
> >
> > Sorry, may be this is not my question, but: I can imagine situation,  
> > where
> > ThreadLocal approach will fail:  it's when we do asynchronics call  
> > to some
> > external entity with callback. In such case callback will not  
> > receive context in
> > ThreadLocal.  And it is possible (and very common approach) to do  
> > this from
> > groovy scripts (as groovy has closures).
>
> I don't understand what would not work... Would you mind giving some
>  details and use cases?
>

For example - write something like 'doParallel' from
http://www.jroller.com/melix/entry/simplifiying_java_util_concurrent_with

It is common to call long external process in one branch (for example fetching
external URL) and check for timeout in other branch.

All closures, which would evaluated inside doParallel will have not access to
ThreadLocal.


> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
In reply to this post by Pascal Voitot
Hi Pascal,

On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:

> Even if I can't say I'm an expert of XWiki yet, let me give my point  
> of
> view...
> The ThreadLocal is interesting but can bring lots of design  
> constraints
> also...
> Moreover, I think the stateless approach would be an insurance for  
> future
> evolutions and passing the context seems better for that...
> For example, I have been thinking about an XWiki engine using service
> oriented approach... without the Servlet model... A raw XWiki service
> provider without knowledge of its communication and presentation  
> layers...
> Like this, it would be easy to imagine P2P, balancing, grid  
> computing etc...
> To my mind, the component model goes in this way...

Actually we're not bound to the Servlet model at all. If you check the  
container component in SNV you'll see that it's made to be generic  
with a first implementation for Servlet (in component-servlet).

The only constraint is that whatever your development model you must  
provide an implementation of the Container API, i.e. implement the  
notion of request, response, session and application context. This is  
what we'll do for example in the scheduler or XMLRPC module.

To be honest, I still need to finish this container component since I  
don't fully know yet how the correct implementation can be passed to  
the component needing the Container object.

Thanks
-Vincent

>
> ThreadLocal and stateless approach may be compliant but I'm sure  
> about this
> :)
>
> Pascal
>
>
> On 4/12/08, rssh <[hidden email]> wrote:
>>
>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>>> Hi,
>>>
>>
>> Sorry, may be this is not my question, but: I can imagine  
>> situation, where
>> ThreadLocal approach will fail:  it's when we do asynchronics call  
>> to some
>> external entity with callback. In such case callback will not receive
>> context in
>> ThreadLocal.  And it is possible (and very common approach) to do  
>> this
>> from
>> groovy scripts (as groovy has closures).
>>
>>
>>
>> --
>> Ruslan Shevchenko
>> GradSoft. http://www.gradsoft.ua
>>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
In reply to this post by rssh

On Apr 12, 2008, at 1:01 PM, rssh wrote:

> On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote
>> Hi Ruslan,
>>
>> On Apr 12, 2008, at 12:02 PM, rssh wrote:
>>
>>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>>>> Hi,
>>>>
>>>
>>> Sorry, may be this is not my question, but: I can imagine situation,
>>> where
>>> ThreadLocal approach will fail:  it's when we do asynchronics call
>>> to some
>>> external entity with callback. In such case callback will not
>>> receive context in
>>> ThreadLocal.  And it is possible (and very common approach) to do
>>> this from
>>> groovy scripts (as groovy has closures).
>>
>> I don't understand what would not work... Would you mind giving some
>> details and use cases?
>>
>
> For example - write something like 'doParallel' from
> http://www.jroller.com/melix/entry/simplifiying_java_util_concurrent_with
>
> It is common to call long external process in one branch (for  
> example fetching
> external URL) and check for timeout in other branch.
>
> All closures, which would evaluated inside doParallel will have not  
> access to
> ThreadLocal.

I don't think we should allow user code in document pages the ability  
to create threads. This is going to be asking for trouble IMO  
(Remember that inside a J2EE container you're not allowed to  
manipulate threads).

However even if we do we can use InheritableThreadLocal as pointed out  
by Artem for example.

-Vincent
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Pascal Voitot
In reply to this post by vmassol
After looking at the code, I see what you mean and the model seems quite
generic and on the good way!

Excuse me for my stupid ideas... wouldn't it be possible to do the same for
the context? The idea is not to be forced to pass it to every call... Could
it be possible to create an abstract and generic mechanism that passes
context and one implementation would be ThreadLocal... And if later, we
discover a strong problem, we could have another implementation...

regards
Pascal


On 4/12/08, Vincent Massol <[hidden email]> wrote:

>
> Hi Pascal,
>
> On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
>
> > Even if I can't say I'm an expert of XWiki yet, let me give my point
> > of
> > view...
> > The ThreadLocal is interesting but can bring lots of design
> > constraints
> > also...
> > Moreover, I think the stateless approach would be an insurance for
> > future
> > evolutions and passing the context seems better for that...
> > For example, I have been thinking about an XWiki engine using service
> > oriented approach... without the Servlet model... A raw XWiki service
> > provider without knowledge of its communication and presentation
> > layers...
> > Like this, it would be easy to imagine P2P, balancing, grid
> > computing etc...
> > To my mind, the component model goes in this way...
>
> Actually we're not bound to the Servlet model at all. If you check the
> container component in SNV you'll see that it's made to be generic
> with a first implementation for Servlet (in component-servlet).
>
> The only constraint is that whatever your development model you must
> provide an implementation of the Container API, i.e. implement the
> notion of request, response, session and application context. This is
> what we'll do for example in the scheduler or XMLRPC module.
>
> To be honest, I still need to finish this container component since I
> don't fully know yet how the correct implementation can be passed to
> the component needing the Container object.
>
> Thanks
> -Vincent
>
> >
> > ThreadLocal and stateless approach may be compliant but I'm sure
> > about this
> > :)
> >
> > Pascal
> >
> >
> > On 4/12/08, rssh <[hidden email]> wrote:
> >>
> >> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
> >>> Hi,
> >>>
> >>
> >> Sorry, may be this is not my question, but: I can imagine
> >> situation, where
> >> ThreadLocal approach will fail:  it's when we do asynchronics call
> >> to some
> >> external entity with callback. In such case callback will not receive
> >> context in
> >> ThreadLocal.  And it is possible (and very common approach) to do
> >> this
> >> from
> >> groovy scripts (as groovy has closures).
> >>
> >>
> >>
> >> --
> >> Ruslan Shevchenko
> >> GradSoft. http://www.gradsoft.ua
> >>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

rssh
In reply to this post by vmassol
>
> I don't think we should allow user code in document pages the
> ability  to create threads. This is going to be asking for trouble
> IMO  
> (Remember that inside a J2EE container you're not allowed to
>  manipulate threads).
>

 Hmm -- I was think about case lightweight Apache/Tomcat.

If we think about J2EE - yes, it's not allowed, but is using ThreadLocal is
allowed inside J2EE application ?  

(And yet one moment to care is
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531
[workaround is cleaning ThreadLocal at the end of each request]
)



 

--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator

On Apr 12, 2008, at 2:21 PM, rssh wrote:

>>
>> I don't think we should allow user code in document pages the
>> ability  to create threads. This is going to be asking for trouble
>> IMO
>> (Remember that inside a J2EE container you're not allowed to
>> manipulate threads).
>>
>
> Hmm -- I was think about case lightweight Apache/Tomcat.
>
> If we think about J2EE - yes, it's not allowed, but is using  
> ThreadLocal is
> allowed inside J2EE application ?

good point! I think it should be ok since once a request is started on  
a container instance, it continues on that same instance.

> (And yet one moment to care is
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531
> [workaround is cleaning ThreadLocal at the end of each request]
> )

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
In reply to this post by Pascal Voitot

On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:

> After looking at the code, I see what you mean and the model seems  
> quite
> generic and on the good way!
>
> Excuse me for my stupid ideas... wouldn't it be possible to do the  
> same for
> the context?

You mean application context? If so then it doesn't mean anything  
since the application context is the same for the whole duration of  
the application. The ThreadLocal is only required for request/response  
and session since those are different per user (thus per thread).

-Vincent

> The idea is not to be forced to pass it to every call... Could
> it be possible to create an abstract and generic mechanism that passes
> context and one implementation would be ThreadLocal... And if later,  
> we
> discover a strong problem, we could have another implementation...
>
> regards
> Pascal
>
>
> On 4/12/08, Vincent Massol <[hidden email]> wrote:
>>
>> Hi Pascal,
>>
>> On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
>>
>>> Even if I can't say I'm an expert of XWiki yet, let me give my point
>>> of
>>> view...
>>> The ThreadLocal is interesting but can bring lots of design
>>> constraints
>>> also...
>>> Moreover, I think the stateless approach would be an insurance for
>>> future
>>> evolutions and passing the context seems better for that...
>>> For example, I have been thinking about an XWiki engine using  
>>> service
>>> oriented approach... without the Servlet model... A raw XWiki  
>>> service
>>> provider without knowledge of its communication and presentation
>>> layers...
>>> Like this, it would be easy to imagine P2P, balancing, grid
>>> computing etc...
>>> To my mind, the component model goes in this way...
>>
>> Actually we're not bound to the Servlet model at all. If you check  
>> the
>> container component in SNV you'll see that it's made to be generic
>> with a first implementation for Servlet (in component-servlet).
>>
>> The only constraint is that whatever your development model you must
>> provide an implementation of the Container API, i.e. implement the
>> notion of request, response, session and application context. This is
>> what we'll do for example in the scheduler or XMLRPC module.
>>
>> To be honest, I still need to finish this container component since I
>> don't fully know yet how the correct implementation can be passed to
>> the component needing the Container object.
>>
>> Thanks
>> -Vincent
>>
>>>
>>> ThreadLocal and stateless approach may be compliant but I'm sure
>>> about this
>>> :)
>>>
>>> Pascal
>>>
>>>
>>> On 4/12/08, rssh <[hidden email]> wrote:
>>>>
>>>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>>>>> Hi,
>>>>>
>>>>
>>>> Sorry, may be this is not my question, but: I can imagine
>>>> situation, where
>>>> ThreadLocal approach will fail:  it's when we do asynchronics call
>>>> to some
>>>> external entity with callback. In such case callback will not  
>>>> receive
>>>> context in
>>>> ThreadLocal.  And it is possible (and very common approach) to do
>>>> this
>>>> from
>>>> groovy scripts (as groovy has closures).
>>>>
>>>>
>>>>
>>>> --
>>>> Ruslan Shevchenko
>>>> GradSoft. http://www.gradsoft.ua
>>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
In reply to this post by Pascal Voitot

On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:

> After looking at the code, I see what you mean and the model seems  
> quite
> generic and on the good way!

The only problem is that I haven't found a way to inject the correct  
implementation of Container in the components that need it.

Thus for now the only solution I have is by passing it to every  
method.... It's the calling code that knows which implementation to  
pass...

Any idea?

Thanks
-Vincent

> Excuse me for my stupid ideas... wouldn't it be possible to do the  
> same for
> the context? The idea is not to be forced to pass it to every  
> call... Could
> it be possible to create an abstract and generic mechanism that passes
> context and one implementation would be ThreadLocal... And if later,  
> we
> discover a strong problem, we could have another implementation...
>
> regards
> Pascal
>
>
> On 4/12/08, Vincent Massol <[hidden email]> wrote:
>>
>> Hi Pascal,
>>
>> On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
>>
>>> Even if I can't say I'm an expert of XWiki yet, let me give my point
>>> of
>>> view...
>>> The ThreadLocal is interesting but can bring lots of design
>>> constraints
>>> also...
>>> Moreover, I think the stateless approach would be an insurance for
>>> future
>>> evolutions and passing the context seems better for that...
>>> For example, I have been thinking about an XWiki engine using  
>>> service
>>> oriented approach... without the Servlet model... A raw XWiki  
>>> service
>>> provider without knowledge of its communication and presentation
>>> layers...
>>> Like this, it would be easy to imagine P2P, balancing, grid
>>> computing etc...
>>> To my mind, the component model goes in this way...
>>
>> Actually we're not bound to the Servlet model at all. If you check  
>> the
>> container component in SNV you'll see that it's made to be generic
>> with a first implementation for Servlet (in component-servlet).
>>
>> The only constraint is that whatever your development model you must
>> provide an implementation of the Container API, i.e. implement the
>> notion of request, response, session and application context. This is
>> what we'll do for example in the scheduler or XMLRPC module.
>>
>> To be honest, I still need to finish this container component since I
>> don't fully know yet how the correct implementation can be passed to
>> the component needing the Container object.
>>
>> Thanks
>> -Vincent
>>
>>>
>>> ThreadLocal and stateless approach may be compliant but I'm sure
>>> about this
>>> :)
>>>
>>> Pascal
>>>
>>>
>>> On 4/12/08, rssh <[hidden email]> wrote:
>>>>
>>>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>>>>> Hi,
>>>>>
>>>>
>>>> Sorry, may be this is not my question, but: I can imagine
>>>> situation, where
>>>> ThreadLocal approach will fail:  it's when we do asynchronics call
>>>> to some
>>>> external entity with callback. In such case callback will not  
>>>> receive
>>>> context in
>>>> ThreadLocal.  And it is possible (and very common approach) to do
>>>> this
>>>> from
>>>> groovy scripts (as groovy has closures).
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Pascal Voitot
In reply to this post by vmassol
see below

On 4/12/08, Vincent Massol <[hidden email]> wrote:

>
>
> On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
>
> > After looking at the code, I see what you mean and the model seems
> > quite
> > generic and on the good way!
> >
> > Excuse me for my stupid ideas... wouldn't it be possible to do the
> > same for
> > the context?
>
> You mean application context? If so then it doesn't mean anything
> since the application context is the same for the whole duration of
> the application. The ThreadLocal is only required for request/response
> and session since those are different per user (thus per thread).


No no, I was speaking about context as XWikiContext or as Container now...
As you say , for AppContext, it means nothing...
I was also speaking about an abstract design to inject the container in
components without be forced to pass it to all functions...
ThreadLocal would be an implementation of this "container injector" but as
it might have counter effects that we don't see today, we should keep the
abstraction so that we can replace it if we find something else...
I'm going to study a bit and think about all of this :)

regards
Pascal




-Vincent

>
> > The idea is not to be forced to pass it to every call... Could
> > it be possible to create an abstract and generic mechanism that passes
> > context and one implementation would be ThreadLocal... And if later,
> > we
> > discover a strong problem, we could have another implementation...
> >
> > regards
> > Pascal
> >
> >
> > On 4/12/08, Vincent Massol <[hidden email]> wrote:
> >>
> >> Hi Pascal,
> >>
> >> On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
> >>
> >>> Even if I can't say I'm an expert of XWiki yet, let me give my point
> >>> of
> >>> view...
> >>> The ThreadLocal is interesting but can bring lots of design
> >>> constraints
> >>> also...
> >>> Moreover, I think the stateless approach would be an insurance for
> >>> future
> >>> evolutions and passing the context seems better for that...
> >>> For example, I have been thinking about an XWiki engine using
> >>> service
> >>> oriented approach... without the Servlet model... A raw XWiki
> >>> service
> >>> provider without knowledge of its communication and presentation
> >>> layers...
> >>> Like this, it would be easy to imagine P2P, balancing, grid
> >>> computing etc...
> >>> To my mind, the component model goes in this way...
> >>
> >> Actually we're not bound to the Servlet model at all. If you check
> >> the
> >> container component in SNV you'll see that it's made to be generic
> >> with a first implementation for Servlet (in component-servlet).
> >>
> >> The only constraint is that whatever your development model you must
> >> provide an implementation of the Container API, i.e. implement the
> >> notion of request, response, session and application context. This is
> >> what we'll do for example in the scheduler or XMLRPC module.
> >>
> >> To be honest, I still need to finish this container component since I
> >> don't fully know yet how the correct implementation can be passed to
> >> the component needing the Container object.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>> ThreadLocal and stateless approach may be compliant but I'm sure
> >>> about this
> >>> :)
> >>>
> >>> Pascal
> >>>
> >>>
> >>> On 4/12/08, rssh <[hidden email]> wrote:
> >>>>
> >>>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
> >>>>> Hi,
> >>>>>
> >>>>
> >>>> Sorry, may be this is not my question, but: I can imagine
> >>>> situation, where
> >>>> ThreadLocal approach will fail:  it's when we do asynchronics call
> >>>> to some
> >>>> external entity with callback. In such case callback will not
> >>>> receive
> >>>> context in
> >>>> ThreadLocal.  And it is possible (and very common approach) to do
> >>>> this
> >>>> from
> >>>> groovy scripts (as groovy has closures).
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ruslan Shevchenko
> >>>> GradSoft. http://www.gradsoft.ua
> >>>>
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator

On Apr 13, 2008, at 1:03 AM, Pascal Voitot wrote:

> see below
>
> On 4/12/08, Vincent Massol <[hidden email]> wrote:
>>
>>
>> On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
>>
>>> After looking at the code, I see what you mean and the model seems
>>> quite
>>> generic and on the good way!
>>>
>>> Excuse me for my stupid ideas... wouldn't it be possible to do the
>>> same for
>>> the context?
>>
>> You mean application context? If so then it doesn't mean anything
>> since the application context is the same for the whole duration of
>> the application. The ThreadLocal is only required for request/
>> response
>> and session since those are different per user (thus per thread).
>
>
> No no, I was speaking about context as XWikiContext or as Container  
> now...

XWikiContext (current) = request + response + session + app context  
(new)

Thanks
-Vincent

>
> As you say , for AppContext, it means nothing...
> I was also speaking about an abstract design to inject the container  
> in
> components without be forced to pass it to all functions...
> ThreadLocal would be an implementation of this "container injector"  
> but as
> it might have counter effects that we don't see today, we should  
> keep the
> abstraction so that we can replace it if we find something else...
> I'm going to study a bit and think about all of this :)
>
> regards
> Pascal
>
>
>
>
> -Vincent
>>
>>> The idea is not to be forced to pass it to every call... Could
>>> it be possible to create an abstract and generic mechanism that  
>>> passes
>>> context and one implementation would be ThreadLocal... And if later,
>>> we
>>> discover a strong problem, we could have another implementation...
>>>
>>> regards
>>> Pascal
>>>
>>>
>>> On 4/12/08, Vincent Massol <[hidden email]> wrote:
>>>>
>>>> Hi Pascal,
>>>>
>>>> On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
>>>>
>>>>> Even if I can't say I'm an expert of XWiki yet, let me give my  
>>>>> point
>>>>> of
>>>>> view...
>>>>> The ThreadLocal is interesting but can bring lots of design
>>>>> constraints
>>>>> also...
>>>>> Moreover, I think the stateless approach would be an insurance for
>>>>> future
>>>>> evolutions and passing the context seems better for that...
>>>>> For example, I have been thinking about an XWiki engine using
>>>>> service
>>>>> oriented approach... without the Servlet model... A raw XWiki
>>>>> service
>>>>> provider without knowledge of its communication and presentation
>>>>> layers...
>>>>> Like this, it would be easy to imagine P2P, balancing, grid
>>>>> computing etc...
>>>>> To my mind, the component model goes in this way...
>>>>
>>>> Actually we're not bound to the Servlet model at all. If you check
>>>> the
>>>> container component in SNV you'll see that it's made to be generic
>>>> with a first implementation for Servlet (in component-servlet).
>>>>
>>>> The only constraint is that whatever your development model you  
>>>> must
>>>> provide an implementation of the Container API, i.e. implement the
>>>> notion of request, response, session and application context.  
>>>> This is
>>>> what we'll do for example in the scheduler or XMLRPC module.
>>>>
>>>> To be honest, I still need to finish this container component  
>>>> since I
>>>> don't fully know yet how the correct implementation can be passed  
>>>> to
>>>> the component needing the Container object.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>
>>>>> ThreadLocal and stateless approach may be compliant but I'm sure
>>>>> about this
>>>>> :)
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>> On 4/12/08, rssh <[hidden email]> wrote:
>>>>>>
>>>>>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
>>>>>>> Hi,
>>>>>>>
>>>>>>
>>>>>> Sorry, may be this is not my question, but: I can imagine
>>>>>> situation, where
>>>>>> ThreadLocal approach will fail:  it's when we do asynchronics  
>>>>>> call
>>>>>> to some
>>>>>> external entity with callback. In such case callback will not
>>>>>> receive
>>>>>> context in
>>>>>> ThreadLocal.  And it is possible (and very common approach) to do
>>>>>> this
>>>>>> from
>>>>>> groovy scripts (as groovy has closures).
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ruslan Shevchenko
>>>>>> GradSoft. http://www.gradsoft.ua
>>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

kaaloo
In reply to this post by vmassol
Hi Vincent,

I recently had an issue with 2 in the following context:

- the framework, in this case exo, expects the container in ThreadLocal
- the component we wished to integrate (a webapp) relied upon its own
thread management for some lower level processing part of which needs
to call the exo platform through an adapter

We initially did not know that the framework depended on this, but
after some exchanges with the exo team we tried the approach they use
in their exo applications which is to setup the ThreadLocal with a
servlet filter. This did not work because of course the adapter thread
did not have its ThreadLocal setup.  We finally ended up putting the
setup code in the adapter thread, because in this case it was the only
point of interaction with exo, but there could have been other points
of interaction, and so its not a general solution.

So in conclusion, my experience is that the technique really needs to
be well documented, especially if wiki level scripting or plugins may
need this type of callback behavior to the xwiki framework through
other frameworks that manage their own threads.

P.S. Didn't know about InheritedThreadLocal, sounds cool.

Luis

On Sat, Apr 12, 2008 at 11:25 AM, Vincent Massol <[hidden email]> wrote:

> Hi,
>
>  In the new xwiki architecture we need to take a call for passing the
>  request, response and session around (what is currently called the
>  XWikiContext). We have 2 solutions:
>  1) we pass it around for all method calls as it's currently done
>  2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html
>  .
>
>  The advantage of solution 2) is that any component in the new
>  architecture can decide to have the Container component injected (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/)
>   and thus be allowed to access the request, response and session
>  objects without having all its method add a Container object passed to
>  it.
>
>  The downside of solution 2) is simply that we associate Unit Of Work
>  with Threads. But since we use a Servlet model and since I don't see
>  any foreseeable future where we would want to use several threads for
>  the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination
>   for some explanation on this.
>
>  So right now and even though ThreadLocal sound a little bit "hackish",
>  I think this is still my preference as it'll save us from having to
>  pass Container objects everywhere.
>
>  Since this is an important architecture decision I wanted to have a
>  vote for it.
>
>  Thanks
>  -Vincent
>
>  _______________________________________________
>  devs mailing list
>  [hidden email]
>  http://lists.xwiki.org/mailman/listinfo/devs
>



--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Pascal Voitot
Vincent, I have a question: do you have idea of who, when and how the right
container will be injected as a ThreadLocal? (was it your question "Any
idea?"some mails ago?)

I'm drawing some parallel with the hibernate session-per-request model which
is easily implemented with ThreadLocal...

About InheritableThreadLocal, I found this:
"ThreadLocal's less thread-safe cousin, InheritableThreadLocal

The ThreadLocal class has a relative, InheritableThreadLocal, which
functions in a similar manner, but is suitable for an entirely different
sort of application. When a thread is created, if it holds values for any
InheritableThreadLocal objects, these values are automatically passed on to
the child process as well. If a child process calls get() on an
InheritableThreadLocal, it sees the same object as the parent would. To
preserve thread-safety, you should use InheritableThreadLocal only for
immutable objects (objects whose state will not ever be changed once
created), because the object is shared between multiple threads.
InheritableThreadLocal is useful for passing data from a parent thread to a
child thread, such as a user id, or a transaction id, but not for stateful
objects like JDBC Connections."
regards
Pascal


On 4/13/08, Luis Arias <[hidden email]> wrote:

>
> Hi Vincent,
>
> I recently had an issue with 2 in the following context:
>
> - the framework, in this case exo, expects the container in ThreadLocal
> - the component we wished to integrate (a webapp) relied upon its own
> thread management for some lower level processing part of which needs
> to call the exo platform through an adapter
>
> We initially did not know that the framework depended on this, but
> after some exchanges with the exo team we tried the approach they use
> in their exo applications which is to setup the ThreadLocal with a
> servlet filter. This did not work because of course the adapter thread
> did not have its ThreadLocal setup.  We finally ended up putting the
> setup code in the adapter thread, because in this case it was the only
> point of interaction with exo, but there could have been other points
> of interaction, and so its not a general solution.
>
> So in conclusion, my experience is that the technique really needs to
> be well documented, especially if wiki level scripting or plugins may
> need this type of callback behavior to the xwiki framework through
> other frameworks that manage their own threads.
>
> P.S. Didn't know about InheritedThreadLocal, sounds cool.
>
> Luis
>
> On Sat, Apr 12, 2008 at 11:25 AM, Vincent Massol <[hidden email]>
> wrote:
> > Hi,
> >
> >  In the new xwiki architecture we need to take a call for passing the
> >  request, response and session around (what is currently called the
> >  XWikiContext). We have 2 solutions:
> >  1) we pass it around for all method calls as it's currently done
> >  2) we use ThreadLocal(s). If you don't know what it is see for ex:
> http://crazybob.org/2006/07/hard-core-java-threadlocal.html
> >  .
> >
> >  The advantage of solution 2) is that any component in the new
> >  architecture can decide to have the Container component injected (see
> http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/
> )
> >   and thus be allowed to access the request, response and session
> >  objects without having all its method add a Container object passed to
> >  it.
> >
> >  The downside of solution 2) is simply that we associate Unit Of Work
> >  with Threads. But since we use a Servlet model and since I don't see
> >  any foreseeable future where we would want to use several threads for
> >  the same unit of work, I don't think this is limitating for us. See
> http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination
> >   for some explanation on this.
> >
> >  So right now and even though ThreadLocal sound a little bit "hackish",
> >  I think this is still my preference as it'll save us from having to
> >  pass Container objects everywhere.
> >
> >  Since this is an important architecture decision I wanted to have a
> >  vote for it.
> >
> >  Thanks
> >  -Vincent
> >
> >  _______________________________________________
> >  devs mailing list
> >  [hidden email]
> >  http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Luis Arias
> +33 6 14 20 87 93
> skype : kaaloo
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Ludovic Dubost-2
In reply to this post by vmassol

I'm not a huge fan of fully absolute variables but as long as we can
guarantee that we have always access to ThreadLocal, I'm fine since it's
a bad idea anyway to share a context from one thread to another (we need
a generic method to clean it up when we do like in the Lucene or
Scheduler plugins).

Now does every case allow ThreadLocal ? Do clustering solutions like
TeraCotta allow it ?

I would prefer if we kept all request specific in one context object
(request, response, etc..)

Ludovic

Vincent Massol wrote:

> Hi,
>
> In the new xwiki architecture we need to take a call for passing the  
> request, response and session around (what is currently called the  
> XWikiContext). We have 2 solutions:
> 1) we pass it around for all method calls as it's currently done
> 2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html 
> .
>
> The advantage of solution 2) is that any component in the new  
> architecture can decide to have the Container component injected (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/)
>   and thus be allowed to access the request, response and session  
> objects without having all its method add a Container object passed to  
> it.
>
> The downside of solution 2) is simply that we associate Unit Of Work  
> with Threads. But since we use a Servlet model and since I don't see  
> any foreseeable future where we would want to use several threads for  
> the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination 
>   for some explanation on this.
>
> So right now and even though ThreadLocal sound a little bit "hackish",  
> I think this is still my preference as it'll save us from having to  
> pass Container objects everywhere.
>
> Since this is an important architecture decision I wanted to have a  
> vote for it.
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>  


--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

Pascal Voitot
I don't really like the ThreadLocal because it seems too much "nice" to be
true and I wonder what is the problem :)
But, after some studying, it seems ThreadLocal might be the
only clever solution in Java for propagating the container without passing
it to all functions. Apparently, speaking performace, ThreadLocal seems to
be ok. The only thing to take care about is cleaning the ThreadLocal to
prevent memory leaks...
Naturally, it implies the strong association between unit of work and thread
but as Vincent said, today, there is not many usecases where a unit of work
could need to be multi-threaded. The only case I can see is the case when a
component would need to call other components which run in other threads
because they perform heavy or asynchronous operations. For example, imagine
you call an external indexing engine or a distributed component. And even in
this case, I wonder if there is a problem with ThreadLocal. In fact, the
only important thing a component requires is the injection of the container
at the right time and in the right scope... and also a safe getter...
Using ThreadLocal, it would be something like (without taking into account
previous context storing/restoring, reduction of lookups and memory leaks)

Component.setContainer(Container c)
{
  threadLocal.set(c);
}
and
Container Component.getContainer()
{
  return threadLocal.get();
}
Using the Servlet model, interceptors might be a simple way to inject the
right container in the component...

I think ThreadLocal will solve 80-90% of our usecases and for the remaining
cases, we will use the plain old Container passed using the injection or
even as a function parameter to the component...

So I VOTE +1 if you keep code as independent as possible from ThreadLocal
using some kind of ContainerInjector from which Component would inherit...

Regards
Pascal

On 4/13/08, Ludovic Dubost <[hidden email]> wrote:

>
>
> I'm not a huge fan of fully absolute variables but as long as we can
> guarantee that we have always access to ThreadLocal, I'm fine since it's
> a bad idea anyway to share a context from one thread to another (we need
> a generic method to clean it up when we do like in the Lucene or
> Scheduler plugins).
>
> Now does every case allow ThreadLocal ? Do clustering solutions like
> TeraCotta allow it ?
>
> I would prefer if we kept all request specific in one context object
> (request, response, etc..)
>
> Ludovic
>
> Vincent Massol wrote:
> > Hi,
> >
> > In the new xwiki architecture we need to take a call for passing the
> > request, response and session around (what is currently called the
> > XWikiContext). We have 2 solutions:
> > 1) we pass it around for all method calls as it's currently done
> > 2) we use ThreadLocal(s). If you don't know what it is see for ex:
> http://crazybob.org/2006/07/hard-core-java-threadlocal.html
> > .
> >
> > The advantage of solution 2) is that any component in the new
> > architecture can decide to have the Container component injected (see
> http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/
> )
> >   and thus be allowed to access the request, response and session
> > objects without having all its method add a Container object passed to
> > it.
> >
> > The downside of solution 2) is simply that we associate Unit Of Work
> > with Threads. But since we use a Servlet model and since I don't see
> > any foreseeable future where we would want to use several threads for
> > the same unit of work, I don't think this is limitating for us. See
> http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination
> >   for some explanation on this.
> >
> > So right now and even though ThreadLocal sound a little bit "hackish",
> > I think this is still my preference as it'll save us from having to
> > pass Container objects everywhere.
> >
> > Since this is an important architecture decision I wanted to have a
> > vote for it.
> >
> > Thanks
> > -Vincent
> >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
>
>
> --
> Ludovic Dubost
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Using ThreadLocal vs passing the Context around for all method calls?

vmassol
Administrator
In reply to this post by Ludovic Dubost-2

On Apr 13, 2008, at 2:21 PM, Ludovic Dubost wrote:

>
> I'm not a huge fan of fully absolute variables

neither am I. I'm still not 100% sure ThreadLocal is the best  
solution...

> but as long as we can
> guarantee that we have always access to ThreadLocal, I'm fine since  
> it's
> a bad idea anyway to share a context from one thread to another (we  
> need
> a generic method to clean it up when we do like in the Lucene or
> Scheduler plugins).
>
> Now does every case allow ThreadLocal ? Do clustering solutions like
> TeraCotta allow it ?

I don't see the problem with clustering solutions since the  
ThreadLocal would be set when the request enters the servlet container  
and removed when the response is sent.

Since a request is going to be handled by the same servlet container  
instance for the duration of the request, I don't see how it could go  
wrong.

> I would prefer if we kept all request specific in one context object
> (request, response, etc..)

Not sure what you mean. Right now in the new container component I  
have one object called Container which holds: application context,  
request, response and session.

Thanks
-Vincent

> Vincent Massol wrote:
>> Hi,
>>
>> In the new xwiki architecture we need to take a call for passing the
>> request, response and session around (what is currently called the
>> XWikiContext). We have 2 solutions:
>> 1) we pass it around for all method calls as it's currently done
>> 2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html
>> .
>>
>> The advantage of solution 2) is that any component in the new
>> architecture can decide to have the Container component injected  
>> (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containers/)
>>  and thus be allowed to access the request, response and session
>> objects without having all its method add a Container object passed  
>> to
>> it.
>>
>> The downside of solution 2) is simply that we associate Unit Of Work
>> with Threads. But since we use a Servlet model and since I don't see
>> any foreseeable future where we would want to use several threads for
>> the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination
>>  for some explanation on this.
>>
>> So right now and even though ThreadLocal sound a little bit  
>> "hackish",
>> I think this is still my preference as it'll save us from having to
>> pass Container objects everywhere.
>>
>> Since this is an important architecture decision I wanted to have a
>> vote for it.
>>
>> Thanks
>> -Vincent
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>
>
> --
> Ludovic Dubost
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12