1:12 p.m.
I am trying to get portlet markup headers working with gatein. This
allows portlets to set content in the html head of the portal page. This
only works if the portlets are processed before the page gets generated,
which is currently not the case.
We can get around this by creating a preRender phase to the webui
lifecycle. This phase would generate the markup for the uicomponent and
store it. When the processRender phase occurs, it will just retrieve
this stored markup.
Adding a new phase to the lifecycle is going to require a bunch of
changes to webui.
I already have a simple proof of concept with a preRender phase that is
working with portlets to allow setting the html head.
Before I get too far with this, I would to know if anyone else has any
better ideas about how to handle this.
We could modify the html head using javascript that gets called when the
page is loaded. This will work and would be easy to implement, but seems
like a hack.
I looked into seeing if we could just modify how the UIPortalApplication
gets rendered so that we wouldn't need to touch the rest of the webui
lifecyle. We could do something like render the html body to a temporary
writer first, but this is a messy hack.
1:31 p.m.
Have you studied the possibility to make the ui component
UIPortalApplication to buffer the content of its rendered children.
When the rendering is terminated the UIPortalApplication component can
do two things:
1/ setup the HTTP headers (if we do support it)
2/ update its state to store the headers and then have them pulled by
the template UIPortalApplication.gtmpl
The control flow could be modified to follow:
1/ called process render on its children and buffer the byte array
response
2/ update its state with the buffered response and the headers
3/ output HTTP headers
4/ call render template to render the UIPortalApplication.gtmpl
5/ in the uicomponent.renderChildren() callback send the buffered
response
6/ in a finally block clear the transient state (buffered response and
headers)
On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
I am trying to get portlet markup headers working with gatein. This
allows portlets to set content in the html head of the portal page.
This
only works if the portlets are processed before the page gets
generated,
which is currently not the case.
We can get around this by creating a preRender phase to the webui
lifecycle. This phase would generate the markup for the uicomponent
and
store it. When the processRender phase occurs, it will just retrieve
this stored markup.
Adding a new phase to the lifecycle is going to require a bunch of
changes to webui.
I already have a simple proof of concept with a preRender phase that
is
working with portlets to allow setting the html head.
Before I get too far with this, I would to know if anyone else has any
better ideas about how to handle this.
We could modify the html head using javascript that gets called when
the
page is loaded. This will work and would be easy to implement, but
seems
like a hack.
I looked into seeing if we could just modify how the
UIPortalApplication
gets rendered so that we wouldn't need to touch the rest of the webui
lifecyle. We could do something like render the html body to a
temporary
writer first, but this is a messy hack.
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
2:16 p.m.
On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
Have you studied the possibility to make the ui component
UIPortalApplication to buffer the content of its rendered children.
The only way to buffer the children it to create a temporary writer and
have the children write their content to that. The children by default
will try to write directly to the response writer. This was one of the
options mentioned in my last email.
I already have something almost finished that will do this.
When the rendering is terminated the UIPortalApplication component
can
do two things:
1/ setup the HTTP headers (if we do support it)
2/ update its state to store the headers and then have them pulled by
the template UIPortalApplication.gtmpl
The control flow could be modified to follow:
1/ called process render on its children and buffer the byte array
response
2/ update its state with the buffered response and the headers
3/ output HTTP headers
4/ call render template to render the UIPortalApplication.gtmpl
5/ in the uicomponent.renderChildren() callback send the buffered
response
6/ in a finally block clear the transient state (buffered response and
headers)
On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
> I am trying to get portlet markup headers working with gatein. This
> allows portlets to set content in the html head of the portal page.
> This
> only works if the portlets are processed before the page gets
> generated,
> which is currently not the case.
>
> We can get around this by creating a preRender phase to the webui
> lifecycle. This phase would generate the markup for the uicomponent
> and
> store it. When the processRender phase occurs, it will just retrieve
> this stored markup.
> Adding a new phase to the lifecycle is going to require a bunch of
> changes to webui.
>
> I already have a simple proof of concept with a preRender phase that
> is
> working with portlets to allow setting the html head.
>
> Before I get too far with this, I would to know if anyone else has any
> better ideas about how to handle this.
>
> We could modify the html head using javascript that gets called when
> the
> page is loaded. This will work and would be easy to implement, but
> seems
> like a hack.
>
> I looked into seeing if we could just modify how the
> UIPortalApplication
> gets rendered so that we wouldn't need to touch the rest of the webui
> lifecyle. We could do something like render the html body to a
> temporary
> writer first, but this is a messy hack.
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
6:29 p.m.
On Wed, 2009-12-02 at 15:16 -0500, Matt Wringe wrote:
On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
> Have you studied the possibility to make the ui component
> UIPortalApplication to buffer the content of its rendered children.
The only way to buffer the children it to create a temporary writer and
have the children write their content to that. The children by default
will try to write directly to the response writer. This was one of the
options mentioned in my last email.
I already have something almost finished that will do this.
patch for it was added here a few days ago:
https://jira.jboss.org/jira/browse/GTNPORTAL-321
The output of the children is sent to a temporary writer before the head
of the page is rendered. Then the page is rendered normally, except it
uses the output from the writer for the child elements.
> When the rendering is terminated the UIPortalApplication
component can
> do two things:
>
> 1/ setup the HTTP headers (if we do support it)
>
> 2/ update its state to store the headers and then have them pulled by
> the template UIPortalApplication.gtmpl
>
> The control flow could be modified to follow:
>
> 1/ called process render on its children and buffer the byte array
> response
> 2/ update its state with the buffered response and the headers
> 3/ output HTTP headers
> 4/ call render template to render the UIPortalApplication.gtmpl
> 5/ in the uicomponent.renderChildren() callback send the buffered
> response
> 6/ in a finally block clear the transient state (buffered response and
> headers)
>
> On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
>
> > I am trying to get portlet markup headers working with gatein. This
> > allows portlets to set content in the html head of the portal page.
> > This
> > only works if the portlets are processed before the page gets
> > generated,
> > which is currently not the case.
> >
> > We can get around this by creating a preRender phase to the webui
> > lifecycle. This phase would generate the markup for the uicomponent
> > and
> > store it. When the processRender phase occurs, it will just retrieve
> > this stored markup.
> > Adding a new phase to the lifecycle is going to require a bunch of
> > changes to webui.
> >
> > I already have a simple proof of concept with a preRender phase that
> > is
> > working with portlets to allow setting the html head.
> >
> > Before I get too far with this, I would to know if anyone else has any
> > better ideas about how to handle this.
> >
> > We could modify the html head using javascript that gets called when
> > the
> > page is loaded. This will work and would be easy to implement, but
> > seems
> > like a hack.
> >
> > I looked into seeing if we could just modify how the
> > UIPortalApplication
> > gets rendered so that we wouldn't need to touch the rest of the webui
> > lifecyle. We could do something like render the html body to a
> > temporary
> > writer first, but this is a messy hack.
> >
> > _______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5:02 p.m.
On Sun, 2009-12-06 at 19:29 -0500, Matt Wringe wrote:
On Wed, 2009-12-02 at 15:16 -0500, Matt Wringe wrote:
> On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
> > Have you studied the possibility to make the ui component
> > UIPortalApplication to buffer the content of its rendered children.
>
> The only way to buffer the children it to create a temporary writer and
> have the children write their content to that. The children by default
> will try to write directly to the response writer. This was one of the
> options mentioned in my last email.
> I already have something almost finished that will do this.
patch for it was added here a few days ago:
https://jira.jboss.org/jira/browse/GTNPORTAL-321
The output of the children is sent to a temporary writer before the head
of the page is rendered. Then the page is rendered normally, except it
uses the output from the writer for the child elements.
I committed the patch yesterday but reverted it back due to performance
degradation with using a temporary writer.
I will need to figure out a way to do with without affecting
performance, or make it configurable so that its off by default.
> > When the rendering is terminated the UIPortalApplication
component can
> > do two things:
> >
> > 1/ setup the HTTP headers (if we do support it)
> >
> > 2/ update its state to store the headers and then have them pulled by
> > the template UIPortalApplication.gtmpl
> >
> > The control flow could be modified to follow:
> >
> > 1/ called process render on its children and buffer the byte array
> > response
> > 2/ update its state with the buffered response and the headers
> > 3/ output HTTP headers
> > 4/ call render template to render the UIPortalApplication.gtmpl
> > 5/ in the uicomponent.renderChildren() callback send the buffered
> > response
> > 6/ in a finally block clear the transient state (buffered response and
> > headers)
> >
> > On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
> >
> > > I am trying to get portlet markup headers working with gatein. This
> > > allows portlets to set content in the html head of the portal page.
> > > This
> > > only works if the portlets are processed before the page gets
> > > generated,
> > > which is currently not the case.
> > >
> > > We can get around this by creating a preRender phase to the webui
> > > lifecycle. This phase would generate the markup for the uicomponent
> > > and
> > > store it. When the processRender phase occurs, it will just retrieve
> > > this stored markup.
> > > Adding a new phase to the lifecycle is going to require a bunch of
> > > changes to webui.
> > >
> > > I already have a simple proof of concept with a preRender phase that
> > > is
> > > working with portlets to allow setting the html head.
> > >
> > > Before I get too far with this, I would to know if anyone else has any
> > > better ideas about how to handle this.
> > >
> > > We could modify the html head using javascript that gets called when
> > > the
> > > page is loaded. This will work and would be easy to implement, but
> > > seems
> > > like a hack.
> > >
> > > I looked into seeing if we could just modify how the
> > > UIPortalApplication
> > > gets rendered so that we wouldn't need to touch the rest of the webui
> > > lifecyle. We could do something like render the html body to a
> > > temporary
> > > writer first, but this is a messy hack.
> > >
> > > _______________________________________________
> > > gatein-dev mailing list
> > > gatein-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
6:12 p.m.
how much was performance degrading ?
On Dec 16, 2009, at 12:02 AM, Matt Wringe wrote:
On Sun, 2009-12-06 at 19:29 -0500, Matt Wringe wrote:
> On Wed, 2009-12-02 at 15:16 -0500, Matt Wringe wrote:
>> On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
>>> Have you studied the possibility to make the ui component
>>> UIPortalApplication to buffer the content of its rendered children.
>>
>> The only way to buffer the children it to create a temporary
>> writer and
>> have the children write their content to that. The children by
>> default
>> will try to write directly to the response writer. This was one of
>> the
>> options mentioned in my last email.
>> I already have something almost finished that will do this.
>
> patch for it was added here a few days ago:
> https://jira.jboss.org/jira/browse/GTNPORTAL-321
>
> The output of the children is sent to a temporary writer before the
> head
> of the page is rendered. Then the page is rendered normally, except
> it
> uses the output from the writer for the child elements.
I committed the patch yesterday but reverted it back due to
performance
degradation with using a temporary writer.
I will need to figure out a way to do with without affecting
performance, or make it configurable so that its off by default.
>>> When the rendering is terminated the UIPortalApplication
>>> component can
>>> do two things:
>>>
>>> 1/ setup the HTTP headers (if we do support it)
>>>
>>> 2/ update its state to store the headers and then have them
>>> pulled by
>>> the template UIPortalApplication.gtmpl
>>>
>>> The control flow could be modified to follow:
>>>
>>> 1/ called process render on its children and buffer the byte array
>>> response
>>> 2/ update its state with the buffered response and the headers
>>> 3/ output HTTP headers
>>> 4/ call render template to render the UIPortalApplication.gtmpl
>>> 5/ in the uicomponent.renderChildren() callback send the buffered
>>> response
>>> 6/ in a finally block clear the transient state (buffered
>>> response and
>>> headers)
>>>
>>> On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
>>>
>>>> I am trying to get portlet markup headers working with gatein.
>>>> This
>>>> allows portlets to set content in the html head of the portal
>>>> page.
>>>> This
>>>> only works if the portlets are processed before the page gets
>>>> generated,
>>>> which is currently not the case.
>>>>
>>>> We can get around this by creating a preRender phase to the webui
>>>> lifecycle. This phase would generate the markup for the
>>>> uicomponent
>>>> and
>>>> store it. When the processRender phase occurs, it will just
>>>> retrieve
>>>> this stored markup.
>>>> Adding a new phase to the lifecycle is going to require a bunch of
>>>> changes to webui.
>>>>
>>>> I already have a simple proof of concept with a preRender phase
>>>> that
>>>> is
>>>> working with portlets to allow setting the html head.
>>>>
>>>> Before I get too far with this, I would to know if anyone else
>>>> has any
>>>> better ideas about how to handle this.
>>>>
>>>> We could modify the html head using javascript that gets called
>>>> when
>>>> the
>>>> page is loaded. This will work and would be easy to implement, but
>>>> seems
>>>> like a hack.
>>>>
>>>> I looked into seeing if we could just modify how the
>>>> UIPortalApplication
>>>> gets rendered so that we wouldn't need to touch the rest of the
>>>> webui
>>>> lifecyle. We could do something like render the html body to a
>>>> temporary
>>>> writer first, but this is a messy hack.
>>>>
>>>> _______________________________________________
>>>> gatein-dev mailing list
>>>> gatein-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
3:47 a.m.
Julien Viet wrote:
how much was performance degrading ?
In shortcut, tests from revision 1010 (before patch commit) show
throughput numbers with big load bigger than 550 samples(HTTP requests)
/ s. In Revision 1012 (after patch commit) best throughput was 463
samples/s. In revision 1025 (after patch reverting) throughput and mean
response time was back to similar values as in revision 1010. Here are
more detailed results from all 3 tests:
1) revision 1010
Nodes: 1, Sessions: 500, active: 500, samples: 50376, throughput 279.8
samples/s, 11,885,653.5 bytes/s, mean response: 79 ms, sampling errors:
0, invalid samples: 50, valid samples: 50326 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 70451, throughput 391.3
samples/s, -11,928,909.7 bytes/s, mean response: 38 ms, sampling errors:
0, invalid samples: 0, valid samples: 70451 (100%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 92851, throughput 515.8
samples/s, -11,928,920.2 bytes/s, mean response: 125 ms, sampling
errors: 0, invalid samples: 23, valid samples: 92828 (99%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 98814, throughput 548.9
samples/s, -11,928,862.6 bytes/s, mean response: 542 ms, sampling
errors: 0, invalid samples: 445, valid samples: 98369 (99%)
Nodes: 1, Sessions: 1700, active: 1700, samples: 99574, throughput 553.1
samples/s, -11,928,824.2 bytes/s, mean response: 1068 ms, sampling
errors: 0, invalid samples: 195, valid samples: 99379 (99%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 98428, throughput 546.7
samples/s, -11,928,648.2 bytes/s, mean response: 1653 ms, sampling
errors: 0, invalid samples: 2771, valid samples: 95657 (97%)
Nodes: 1, Sessions: 2300, active: 2300, samples: 97263, throughput 540.3
samples/s, -11,928,892.2 bytes/s, mean response: 2181 ms, sampling
errors: 0, invalid samples: 3669, valid samples: 93594 (96%)
Nodes: 1, Sessions: 2600, active: 2600, samples: 100675, throughput
559.2 samples/s, -11,928,728.3 bytes/s, mean response: 2598 ms, sampling
errors: 13, invalid samples: 7717, valid samples: 92945 (92%)
2) Revision 1012
Nodes: 1, Sessions: 500, active: 500, samples: 48988, throughput 272.1
samples/s, 11,461,718.4 bytes/s, mean response: 137 ms, sampling errors:
0, invalid samples: 50, valid samples: 48938 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 64433, throughput 357.9
samples/s, -11,928,733.8 bytes/s, mean response: 232 ms, sampling
errors: 0, invalid samples: 211, valid samples: 64222 (99%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 83344, throughput 463.0
samples/s, -11,928,876.1 bytes/s, mean response: 366 ms, sampling
errors: 0, invalid samples: 362, valid samples: 82982 (99%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 79022, throughput 439.0
samples/s, -11,928,803.7 bytes/s, mean response: 1189 ms, sampling
errors: 0, invalid samples: 1462, valid samples: 77560 (98%)
Nodes: 1, Sessions: 1700, active: 1699, samples: 71334, throughput 396.2
samples/s, -11,928,857.3 bytes/s, mean response: 2251 ms, sampling
errors: 0, invalid samples: 3305, valid samples: 68029 (95%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 72807, throughput 404.4
samples/s, -11,928,893.2 bytes/s, mean response: 2865 ms, sampling
errors: 0, invalid samples: 5460, valid samples: 67347 (92%)
Nodes: 1, Sessions: 2300, active: 2291, samples: 74245, throughput 412.4
samples/s, -11,928,861.8 bytes/s, mean response: 3423 ms, sampling
errors: 41, invalid samples: 6930, valid samples: 67274 (90%)
3) Revision 1025
Nodes: 1, Sessions: 500, active: 500, samples: 50123, throughput 278.4
samples/s, 11,879,908.4 bytes/s, mean response: 85 ms, sampling errors:
0, invalid samples: 50, valid samples: 50073 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 71070, throughput 394.8
samples/s, -11,928,707.7 bytes/s, mean response: 21 ms, sampling errors:
0, invalid samples: 0, valid samples: 71070 (100%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 94914, throughput 527.2
samples/s, -11,928,737.8 bytes/s, mean response: 80 ms, sampling errors:
0, invalid samples: 0, valid samples: 94914 (100%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 102960, throughput
571.9 samples/s, -11,928,745.6 bytes/s, mean response: 441 ms, sampling
errors: 0, invalid samples: 445, valid samples: 102515 (99%)
Nodes: 1, Sessions: 1700, active: 1700, samples: 100837, throughput
560.1 samples/s, -11,928,794.4 bytes/s, mean response: 1025 ms, sampling
errors: 0, invalid samples: 190, valid samples: 100647 (99%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 99385, throughput 552.1
samples/s, -11,928,724.3 bytes/s, mean response: 1621 ms, sampling
errors: 0, invalid samples: 2405, valid samples: 96980 (97%)
Nodes: 1, Sessions: 2300, active: 2300, samples: 99707, throughput 553.9
samples/s, -11,928,730.3 bytes/s, mean response: 2071 ms, sampling
errors: 3, invalid samples: 4123, valid samples: 95581 (95%)
On Dec 16, 2009, at 12:02 AM, Matt Wringe wrote:
> On Sun, 2009-12-06 at 19:29 -0500, Matt Wringe wrote:
>
>> On Wed, 2009-12-02 at 15:16 -0500, Matt Wringe wrote:
>>
>>> On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
>>>
>>>> Have you studied the possibility to make the ui component
>>>> UIPortalApplication to buffer the content of its rendered children.
>>>>
>>> The only way to buffer the children it to create a temporary
>>> writer and
>>> have the children write their content to that. The children by
>>> default
>>> will try to write directly to the response writer. This was one of
>>> the
>>> options mentioned in my last email.
>>> I already have something almost finished that will do this.
>>>
>> patch for it was added here a few days ago:
>> https://jira.jboss.org/jira/browse/GTNPORTAL-321
>>
>> The output of the children is sent to a temporary writer before the
>> head
>> of the page is rendered. Then the page is rendered normally, except
>> it
>> uses the output from the writer for the child elements.
>>
> I committed the patch yesterday but reverted it back due to
> performance
> degradation with using a temporary writer.
> I will need to figure out a way to do with without affecting
> performance, or make it configurable so that its off by default.
>
>
>>>> When the rendering is terminated the UIPortalApplication
>>>> component can
>>>> do two things:
>>>>
>>>> 1/ setup the HTTP headers (if we do support it)
>>>>
>>>> 2/ update its state to store the headers and then have them
>>>> pulled by
>>>> the template UIPortalApplication.gtmpl
>>>>
>>>> The control flow could be modified to follow:
>>>>
>>>> 1/ called process render on its children and buffer the byte array
>>>> response
>>>> 2/ update its state with the buffered response and the headers
>>>> 3/ output HTTP headers
>>>> 4/ call render template to render the UIPortalApplication.gtmpl
>>>> 5/ in the uicomponent.renderChildren() callback send the buffered
>>>> response
>>>> 6/ in a finally block clear the transient state (buffered
>>>> response and
>>>> headers)
>>>>
>>>> On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:
>>>>
>>>>
>>>>> I am trying to get portlet markup headers working with gatein.
>>>>> This
>>>>> allows portlets to set content in the html head of the portal
>>>>> page.
>>>>> This
>>>>> only works if the portlets are processed before the page gets
>>>>> generated,
>>>>> which is currently not the case.
>>>>>
>>>>> We can get around this by creating a preRender phase to the webui
>>>>> lifecycle. This phase would generate the markup for the
>>>>> uicomponent
>>>>> and
>>>>> store it. When the processRender phase occurs, it will just
>>>>> retrieve
>>>>> this stored markup.
>>>>> Adding a new phase to the lifecycle is going to require a bunch of
>>>>> changes to webui.
>>>>>
>>>>> I already have a simple proof of concept with a preRender phase
>>>>> that
>>>>> is
>>>>> working with portlets to allow setting the html head.
>>>>>
>>>>> Before I get too far with this, I would to know if anyone else
>>>>> has any
>>>>> better ideas about how to handle this.
>>>>>
>>>>> We could modify the html head using javascript that gets called
>>>>> when
>>>>> the
>>>>> page is loaded. This will work and would be easy to implement, but
>>>>> seems
>>>>> like a hack.
>>>>>
>>>>> I looked into seeing if we could just modify how the
>>>>> UIPortalApplication
>>>>> gets rendered so that we wouldn't need to touch the rest of the
>>>>> webui
>>>>> lifecyle. We could do something like render the html body to a
>>>>> temporary
>>>>> writer first, but this is a messy hack.
>>>>>
>>>>> _______________________________________________
>>>>> gatein-dev mailing list
>>>>> gatein-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>
>>> _______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5769
days inactive
5783
days old
6 comments
3 participants
participants (3)
-
Julien Viet -
Marek Posolda -
Matt Wringe