3:20 p.m.
>>>> On Wed, 16 Feb 2011 11:58:56 -0500, Stephen Kenna
<kenna(a)us.ibm.com> said:
SK> Just looking for a quick clarification on the following statement:
SK> Make the composite component feature usable so a "component server" can
be
SK> included in a portlet runtime such that portlets can use the components in
SK> context-dependent ways. This feature is known as "remote components" in
SK> the portlet community.
SK> Is 'remote components' referring to WSRP?
No, this is a new idea that was kicking around from the time we
developed the composite component feature and Mike Freedman from the
Portlet spec suggested something very similar. Considering that a
composite component declares its interface and impl in markup, it's
possible to allow your deployed composite component library to be served
up in response to simple get requests.
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
SK> you have referred to the existing JSR 329 which was written for JSF 1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
11:31 a.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
Speaking as the spec lead of the Portlet Bridge ... my take on this
.... inline.
On 2/17/2011 1:20 PM, Ed Burns wrote:
>>>>> On Wed, 16 Feb 2011 11:58:56 -0500, Stephen
Kenna<kenna(a)us.ibm.com> said:
SK> Just looking for a quick clarification on the following statement:
SK> Make the composite component feature usable so a "component server" can
be
SK> included in a portlet runtime such that portlets can use the components in
SK> context-dependent ways. This feature is known as "remote components"
in
SK> the portlet community.
SK> Is 'remote components' referring to WSRP?
No, this is a new idea that was kicking around from the time we
developed the composite component feature and Mike Freedman from the
Portlet spec suggested something very similar. Considering that a
composite component declares its interface and impl in markup, it's
possible to allow your deployed composite component library to be served
up in response to simple get requests.
My answer would be yes and no. What I am hoping is designed is support
for composite component implementations that are independent from their
declaration. Furthermore, I am hoping that such a design allows such
implementations to be remote from the web application using them (it).
Lastly, I am hoping that such a design has the flexibility that allows
for differing remote provider implementations/platforms to be used to
satisfy/proxy/bind remote composite components. Yes, as Ed indicates
above one such provider might be based on REST. But this is where I
answer yes to your question, I for one intend to work hard at supporting
a provider based on the portlet technologies. So, yes, in such a case
when the composite component is truly remote, WSRP would be the
underlying protocol used for communication.
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet
Bridge? I see
SK> you have referred to the existing JSR 329 which was written for JSF 1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being
looked at. However, as JSF 2.0 has already been out for some time, its
currently felt we would better support the community by publishing a
stable, working implementation of such a bridge based on logical
extensions/migration of JSR 329 before getting into the thick of the JSR
process which tends to be more methodical. To that end there is now a
3.0.x Trunk in svn of the Apache MyFaces PortletBridge project (where
the JSR RI work is):
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x
. This code is stable enough for an alpha release in that it passes the
upgraded version of the 329 TCK and runs the various Ajax and
CompositeComponent samples I could find on the web/in Mojarra. I will
be doing an official (alpha) release shortly once I have clearance. But
in the meantime, interested parties can build/use it directly from this
repository. FYI ... anyone wanting to do so may want to contact me as I
have found bugs in both Mojarra and MyFaces that prevent proper
execution in a portlet environment. I can suggest/provide various
patches to get around these problems.
Finally, since the question was asked here -- when proposed the Bridge
JSR a few years ago there was a discussion on whether it needed to be
separated from JSF or not. At the time we argued that it should be
because the nuances of the portlet environment needed the focus of that
community more than the JSF community. Now that the core of the bridge
have been defined, standardized, and proven to work in practice, its
useful to revisit this question. Given that the underlying portlet spec
is both stable and unlikely to change in the near or medium future, it
seems that the bridge is now pretty much only tied to future JSF
enhancements. Is it time to tie this work closer to the JSF standards
work? If so, what form do you think this should take?
-Mike-
Ed
11:19 a.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I
> see
> SK> you have referred to the existing JSR 329 which was written for JSF
> 1.2.
>
> Personally, I think we do need to open up such a JSR, and having IBM's
> support for such a JSR would be very helpful. However, what *I'm*
> trying to establish is support for a new JSR for JSF. A portlet JSR is
> another matter entirely.
>
Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being
looked at. However, as JSF 2.0 has already been out for some time, its
currently felt we would better support the community by publishing a stable,
working implementation of such a bridge based on logical
extensions/migration of JSR 329 before getting into the thick of the JSR
process which tends to be more methodical. To that end there is now a 3.0.x
Trunk in svn of the Apache MyFaces PortletBridge project (where the JSR RI
work is):
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x .
This code is stable enough for an alpha release in that it passes the
upgraded version of the 329 TCK and runs the various Ajax and
CompositeComponent samples I could find on the web/in Mojarra. I will be
doing an official (alpha) release shortly once I have clearance. But in the
meantime, interested parties can build/use it directly from this repository.
FYI ... anyone wanting to do so may want to contact me as I have found bugs
in both Mojarra and MyFaces that prevent proper execution in a portlet
environment. I can suggest/provide various patches to get around these
problems.
It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge) and
Neil Griffin (portletfaces bridge) about this; I believe they both support
JSF 2 currently, but I'm not sure if they're using standard extension points
or not.
Finally, since the question was asked here -- when proposed the Bridge JSR
a few years ago there was a discussion on whether it needed to be separated
from JSF or not. At the time we argued that it should be because the
nuances of the portlet environment needed the focus of that community more
than the JSF community. Now that the core of the bridge have been defined,
standardized, and proven to work in practice, its useful to revisit this
question. Given that the underlying portlet spec is both stable and
unlikely to change in the near or medium future, it seems that the bridge is
now pretty much only tied to future JSF enhancements. Is it time to tie
this work closer to the JSF standards work? If so, what form do you think
this should take?
Given how slowly this process moves, I think it probably makes sense to keep
them separate, personally. We never get through all of the things we'd like
to for JSF all by itself..
-- Kito
-Mike-
Ed
>
>
1:27 p.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
Thanks for the explanation Mike. I believe that 'remote components' is a
worthwhile goal to put into 2.2. I will inform our Portal/Portlet
Container team so we can get as many eyes looking at this new section as
possible.
Kito,
Thanks for pulling in Neil and Wesley.
I think it still makes sense to keep the JSF spec and the Portlet bridge
spec separate. I just think that we should make sure we produce, at the
very least, a MR for the bridge for any new content in JSF that affects
it. I also think a future bridge spec should have its own version instead
of using the current version of JSF and Portlet in its title. Ed's
inclusion of a JSF 1.2 bridge spec could be seen as confusing.
Regards,
Stephen
stephen kenna ibm websphere
architecture & development
websphere platform web tier lead architect and jsf eg member | address:
4205 s miami blvd, durham, nc 27703 | office: m215/503
email: kenna(a)us.ibm.com | phone: (919) 543-5593 | t/l: 441-5593 |
mobile: (919) 454-1231 | fax: (919) 254-5250
From:
Kito Mann <kito.mann(a)virtua.com>
To:
jsr-314-open(a)jcp.org
Cc:
Neil Griffin <neil.griffin(a)tritonsvc.com>, Wesley Hales
<whales(a)redhat.com>
Date:
02/25/2011 12:21 PM
Subject:
Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
Sent by:
jsr-314-open-bounces(a)jcp.org
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I
see
SK> you have referred to the existing JSR 329 which was written for JSF
1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being
looked at. However, as JSF 2.0 has already been out for some time, its
currently felt we would better support the community by publishing a
stable, working implementation of such a bridge based on logical
extensions/migration of JSR 329 before getting into the thick of the JSR
process which tends to be more methodical. To that end there is now a
3.0.x Trunk in svn of the Apache MyFaces PortletBridge project (where the
JSR RI work is):
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x .
This code is stable enough for an alpha release in that it passes the
upgraded version of the 329 TCK and runs the various Ajax and
CompositeComponent samples I could find on the web/in Mojarra. I will be
doing an official (alpha) release shortly once I have clearance. But in
the meantime, interested parties can build/use it directly from this
repository. FYI ... anyone wanting to do so may want to contact me as I
have found bugs in both Mojarra and MyFaces that prevent proper execution
in a portlet environment. I can suggest/provide various patches to get
around these problems.
It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge) and
Neil Griffin (portletfaces bridge) about this; I believe they both support
JSF 2 currently, but I'm not sure if they're using standard extension
points or not.
Finally, since the question was asked here -- when proposed the Bridge JSR
a few years ago there was a discussion on whether it needed to be
separated from JSF or not. At the time we argued that it should be
because the nuances of the portlet environment needed the focus of that
community more than the JSF community. Now that the core of the bridge
have been defined, standardized, and proven to work in practice, its
useful to revisit this question. Given that the underlying portlet spec
is both stable and unlikely to change in the near or medium future, it
seems that the bridge is now pretty much only tied to future JSF
enhancements. Is it time to tie this work closer to the JSF standards
work? If so, what form do you think this should take?
Given how slowly this process moves, I think it probably makes sense to
keep them separate, personally. We never get through all of the things
we'd like to for JSF all by itself..
-- Kito
-Mike-
Ed
11 a.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
Hi Guys,
I think keeping the JSF and Portlet Bridge JSRs separate is fine. Historically we've
had good communication between the two, but for JSF 2.2 I think we need to combine that
with tight coordination and scheduling.
Best Regards to all,
Neil
On Feb 27, 2011, at 2:27 PM, Stephen Kenna wrote:
Thanks for the explanation Mike. I believe that 'remote
components' is a worthwhile goal to put into 2.2. I will inform our Portal/Portlet
Container team so we can get as many eyes looking at this new section as possible.
Kito,
Thanks for pulling in Neil and Wesley.
I think it still makes sense to keep the JSF spec and the Portlet bridge spec separate.
I just think that we should make sure we produce, at the very least, a MR for the bridge
for any new content in JSF that affects it. I also think a future bridge spec should have
its own version instead of using the current version of JSF and Portlet in its title.
Ed's inclusion of a JSF 1.2 bridge spec could be seen as confusing.
Regards,
Stephen
<Mail Attachment.gif>
stephen kenna ibm websphere architecture &
development
websphere platform web tier lead architect and jsf eg member | address: 4205 s miami
blvd, durham, nc 27703 | office: m215/503
email: kenna(a)us.ibm.com | phone: (919) 543-5593 | t/l: 441-5593 | mobile: (919)
454-1231 | fax: (919) 254-5250
From: Kito Mann <kito.mann(a)virtua.com>
To: jsr-314-open(a)jcp.org
Cc: Neil Griffin <neil.griffin(a)tritonsvc.com>, Wesley Hales
<whales(a)redhat.com>
Date: 02/25/2011 12:21 PM
Subject: Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
Sent by: jsr-314-open-bounces(a)jcp.org
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
SK> you have referred to the existing JSR 329 which was written for JSF 1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being looked at.
However, as JSF 2.0 has already been out for some time, its currently felt we would better
support the community by publishing a stable, working implementation of such a bridge
based on logical extensions/migration of JSR 329 before getting into the thick of the JSR
process which tends to be more methodical. To that end there is now a 3.0.x Trunk in svn
of the Apache MyFaces PortletBridge project (where the JSR RI work is):
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x . This code is
stable enough for an alpha release in that it passes the upgraded version of the 329 TCK
and runs the various Ajax and CompositeComponent samples I could find on the web/in
Mojarra. I will be doing an official (alpha) release shortly once I have clearance. But
in the meantime, interested parties can build/use it directly from this repository. FYI
... anyone wanting to do so may want to contact me as I have found bugs in both Mojarra
and MyFaces that prevent proper execution in a portlet environment. I can suggest/provide
various patches to get around these problems.
It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge) and Neil
Griffin (portletfaces bridge) about this; I believe they both support JSF 2 currently, but
I'm not sure if they're using standard extension points or not.
Finally, since the question was asked here -- when proposed the Bridge JSR a few years
ago there was a discussion on whether it needed to be separated from JSF or not. At the
time we argued that it should be because the nuances of the portlet environment needed the
focus of that community more than the JSF community. Now that the core of the bridge have
been defined, standardized, and proven to work in practice, its useful to revisit this
question. Given that the underlying portlet spec is both stable and unlikely to change in
the near or medium future, it seems that the bridge is now pretty much only tied to future
JSF enhancements. Is it time to tie this work closer to the JSF standards work? If so,
what form do you think this should take?
Given how slowly this process moves, I think it probably makes sense to keep them
separate, personally. We never get through all of the things we'd like to for JSF all
by itself..
-- Kito
-Mike-
Ed
3:55 p.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
I also prefer to keep these specs separately, but they definitely have
to be designed together. Currently, portlet spec followes a moving
target and tries to resolve problems on their own.
I've started version 3.0 for jboss portlet bridge as well (
https://svn.jboss.org/repos/portletbridge/branches/3.0.X ), and there
are some problems faced to date:
- JSF resources. Bridge spec requires ExternalContext#encodeResourceURL
call to convert url's from the Servlet to Portlet format. Unfortunately,
JSF renders resource URL's without call to that method, so they don't
converted to the portal form. I tried to wrap all resources and encode
url in modified getResourcePath method. To make things worse, resources
passed as el-expression ( ${resource:...} ) sometime went to the
encodeResourceUrl method, that makes harder to avoid double encoding there.
- ResponseStateManager.VIEW_STATE_PARAM should be namespaced, or, at
least, converted to the configurable value similar to the clientId
delimiter. Otherwise, client-side part updates state field for all JSF
portlets on the page.
- JavaScript namespacing. To do that, javascript files should be
processed for el-expressions substitution, same way as it done for
stylesheets. standard jsf.js should use
#{externalContext.encodeNamespace('jsf')} instead of direct names
jsf.ajax and jsf.util.
- Portlet 2.0 ( JSR-286 ) introduces 2 types of render request. The
first one going to render elements that included in the <head> element
for the portal page, the second is for portlet page itself. I already
suggested to implement similar functionality for JSF encode phase (
encodeHead and encodeBody ), to allow components add their dependencies
to head 'on the fly'. The simplest way to aim that would be 'EncodeHead'
system event fired by the <h:head> component.
- occational use for servlet classes. That's more for the implementation
developers, but using '*Servlet*' classes in the framework should be
PROHIBITED by spec. period. Any time, when direct access for servlet
classes required, it should be considered as missing ExternalContext
functionality.
From the portlet bridge side, the new spec has to define how to
implement new methods from the ExternslContext, how to process page
parameters, what's Flash scope means for portlets, how to render portlet
page, PartialViewContext requirements and so on.
On 02/28/2011 09:00 AM, Neil Griffin wrote:
Hi Guys,
I think keeping the JSF and Portlet Bridge JSRs separate is fine.
Historically we've had good communication between the two, but for JSF
2.2 I think we need to combine that with tight coordination and scheduling.
Best Regards to all,
Neil
On Feb 27, 2011, at 2:27 PM, Stephen Kenna wrote:
> Thanks for the explanation Mike. I believe that 'remote components' is
> a worthwhile goal to put into 2.2. I will inform our Portal/Portlet
> Container team so we can get as many eyes looking at this new section
> as possible.
>
> Kito,
> Thanks for pulling in Neil and Wesley.
>
> I think it still makes sense to keep the JSF spec and the Portlet
> bridge spec separate. I just think that we should make sure we
> produce, at the very least, a MR for the bridge for any new content in
> JSF that affects it. I also think a future bridge spec should have its
> own version instead of using the current version of JSF and Portlet in
> its title. Ed's inclusion of a JSF 1.2 bridge spec could be seen as
> confusing.
>
>
> Regards,
> Stephen
>
> <Mail Attachment.gif>*
> stephen kenna ibm websphere architecture & development*
> websphere platform web tier lead architect and jsf eg member |
> _address:_ 4205 s miami blvd, durham, nc 27703 | _office:_ m215/503_
> email:_ kenna(a)us.ibm.com <mailto:kenna@us.ibm.com> | _phone:_ (919)
> 543-5593 | _t/l:_ 441-5593 | _mobile:_ (919) 454-1231 | _fax:_ (919)
> 254-5250
>
>
> From: Kito Mann <kito.mann(a)virtua.com <mailto:kito.mann@virtua.com>>
> To: jsr-314-open(a)jcp.org <mailto:jsr-314-open@jcp.org>
> Cc: Neil Griffin <neil.griffin(a)tritonsvc.com
> <mailto:neil.griffin@tritonsvc.com>>, Wesley Hales <whales(a)redhat.com
> <mailto:whales@redhat.com>>
> Date: 02/25/2011 12:21 PM
> Subject: Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
> Sent by: jsr-314-open-bounces(a)jcp.org
> <mailto:jsr-314-open-bounces@jcp.org>
>
>
> ------------------------------------------------------------------------
>
>
>
>
> SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
> SK> you have referred to the existing JSR 329 which was written for
> JSF 1.2.
>
> Personally, I think we do need to open up such a JSR, and having IBM's
> support for such a JSR would be very helpful. However, what *I'm*
> trying to establish is support for a new JSR for JSF. A portlet JSR is
> another matter entirely.
>
> Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently
> being looked at. However, as JSF 2.0 has already been out for some
> time, its currently felt we would better support the community by
> publishing a stable, working implementation of such a bridge based on
> logical extensions/migration of JSR 329 before getting into the thick
> of the JSR process which tends to be more methodical. To that end
> there is now a 3.0.x Trunk in svn of the Apache MyFaces PortletBridge
> project (where the JSR RI work is):
> _https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x_.
> This code is stable enough for an alpha release in that it passes the
> upgraded version of the 329 TCK and runs the various Ajax and
> CompositeComponent samples I could find on the web/in Mojarra. I will
> be doing an official (alpha) release shortly once I have clearance.
> But in the meantime, interested parties can build/use it directly from
> this repository. FYI ... anyone wanting to do so may want to contact
> me as I have found bugs in both Mojarra and MyFaces that prevent
> proper execution in a portlet environment. I can suggest/provide
> various patches to get around these problems.
>
> It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge)
> and Neil Griffin (portletfaces bridge) about this; I believe they both
> support JSF 2 currently, but I'm not sure if they're using standard
> extension points or not.
>
> Finally, since the question was asked here -- when proposed the Bridge
> JSR a few years ago there was a discussion on whether it needed to be
> separated from JSF or not. At the time we argued that it should be
> because the nuances of the portlet environment needed the focus of
> that community more than the JSF community. Now that the core of the
> bridge have been defined, standardized, and proven to work in
> practice, its useful to revisit this question. Given that the
> underlying portlet spec is both stable and unlikely to change in the
> near or medium future, it seems that the bridge is now pretty much
> only tied to future JSF enhancements. Is it time to tie this work
> closer to the JSF standards work? If so, what form do you think this
> should take?
>
> Given how slowly this process moves, I think it probably makes sense
> to keep them separate, personally. We never get through all of the
> things we'd like to for JSF all by itself..
>
> -- Kito
>
> -Mike-
>
> Ed
>
>
>
7:11 a.m.
New subject: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
On Feb 25, 2011, at 12:19 PM, Kito Mann wrote:
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
SK> you have referred to the existing JSR 329 which was written for JSF 1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being looked at.
However, as JSF 2.0 has already been out for some time, its currently felt we would better
support the community by publishing a stable, working implementation of such a bridge
based on logical extensions/migration of JSR 329 before getting into the thick of the JSR
process which tends to be more methodical. To that end there is now a 3.0.x Trunk in svn
of the Apache MyFaces PortletBridge project (where the JSR RI work is):
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x . This code is
stable enough for an alpha release in that it passes the upgraded version of the 329 TCK
and runs the various Ajax and CompositeComponent samples I could find on the web/in
Mojarra. I will be doing an official (alpha) release shortly once I have clearance. But
in the meantime, interested parties can build/use it directly from this repository. FYI
... anyone wanting to do so may want to contact me as I have found bugs in both Mojarra
and MyFaces that prevent proper execution in a portlet environment. I can suggest/provide
various patches to get around these problems.
It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge) and Neil
Griffin (portletfaces bridge) about this; I believe they both support JSF 2 currently, but
I'm not sure if they're using standard extension points or not.
Yup, agree if we really want to have portal support as a keystone requirement we need to
have these guys involved. I've already contacted Wesley and he is working on some
initial feedback. I think it is also important that Alex Smirnov be involved as he has
extensive experience with portal/JSF issues.
Besides these people mentioned here, who are the portal integration guru's for this
effort, and how do we make sure they are involved?
Finally, since the question was asked here -- when proposed the Bridge JSR a few years
ago there was a discussion on whether it needed to be separated from JSF or not. At the
time we argued that it should be because the nuances of the portlet environment needed the
focus of that community more than the JSF community. Now that the core of the bridge have
been defined, standardized, and proven to work in practice, its useful to revisit this
question. Given that the underlying portlet spec is both stable and unlikely to change in
the near or medium future, it seems that the bridge is now pretty much only tied to future
JSF enhancements. Is it time to tie this work closer to the JSF standards work? If so,
what form do you think this should take?
Given how slowly this process moves, I think it probably makes sense to keep them
separate, personally. We never get through all of the things we'd like to for JSF all
by itself..
-- Kito
-Mike-
Ed
5044
days inactive
5056
days old
jsr-314-open-mirror@lists.jboss.org
6 comments
7 participants
participants (7)
-
Alexander Smirnov -
Ed Burns -
Jay Balunas -
Kito Mann -
Michael Freedman -
Neil Griffin -
Stephen Kenna