XForms/JSF Form Submission

Hi guys,

at the moment I'm a bit confused. Maybe I'm just thinking too much (or too
less). :)

Is anybody out there using XForms with JSF that could tell me how to process
an XForms submission without leaving the JSF framework?

Basically I'd like to specify an XForms submission like this:

<xforms:submission action="#{myJsfHandler.processXformsSubmission}"
      method="post" id="mySubmit" ref="instance('myInstance')" />


The JSF handler "myJsfHandler" should be called when the submission is
executed (by pressing a button). Depending on the outcome of the method
"processXformsSubmission", the JSF navigation definition should be used to
load the next JSF page.

Is something like this possible? Or how do I process XForms submissions in
an JSF environment?

This may sound trivial, but currently this is really confusing me. I'm at a
loss.  :(

- bitbyter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter wrote: It certainly doesn't sound trivial. I have to confess I have no clue how
you want these two frameworks to work together. The XForms submission
will submit to a URL. Then the result of that URL will be a new page
which will load in your browser. That's how a submission with
replace="all" (the default) is meant to work.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Erik,

Wednesday, May 16, 2007, 6:30:55 PM, you wrote:

> It certainly doesn't sound trivial. I have to confess I have no clue how
> you want these two frameworks to work together. The XForms submission
> will submit to a URL. Then the result of that URL will be a new page
> which will load in your browser. That's how a submission with
> replace="all" (the default) is meant to work.

Well, at http://www-128.ibm.com/developerworks/edu/j-dw-java-jsfx-i.html I
found a paper about JSF-XForms integration. The trick seems to be to wrap
the XForms controls within own JSF controls. This way it seems possible
to register an action handler for XForms controls. But I need to go through
that paper in detail.

What keeps me thinking is the fact that an XForms browser plugin,
respectively an XForms browser is used in that paper. I'm not sure if and in
what way this may be different when using Orbeon Forms instead? What do you
think?

- bitbyter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter wrote: Hard to tell without reading the 13 pages of that article. Please let us
know what you find ;-)

One question I have to ask is whether it is worth integrating JSF and
XForms this way. JSF has a set of controls, and so does XForms. JSF uses
beans to store data, XForms uses XML documents (instances). JSF has an
event model, XForms has its own. Etc.

So really we have two different systems trying to solve the same
problem. Making the two of them work together in a same page seems to be
a challenge. Not necessarily impossible, but challenging nonetheless.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Erik,

Friday, May 18, 2007, 3:58:31 PM, you wrote:

> Hard to tell without reading the 13 pages of that article. Please let us
> know what you find ;-)

Basically it should work. It's basically achieved by wrapping the
<xforms:submit> control into an own JSP <jsf:submitButton> component which
renders that <xforms:submit> control. This allows to register an JSF event
handler for the button.

Unfortunately the sample application that comes with the article does not
work with Orbeon Forms. The custom JSF component renders XForms
tags/controls, which do not get transformed into XHTML by the Orbeon Filter.
Any idea why this transformation into XHTML does not work within the Orbeon
XForms filter?

> One question I have to ask is whether it is worth integrating JSF and
> XForms this way. JSF has a set of controls, and so does XForms. JSF uses
> beans to store data, XForms uses XML documents (instances). JSF has an
> event model, XForms has its own. Etc.

Well, XForms technology got some benefits like dynamically adding or
removing form elements without great effort, as it is with JSF. So I'd just
like to add these benefits to our JSF application. Unfortunately the current
web browsers do not support XForms natively, else we would not have this
talk. :)

> So really we have two different systems trying to solve the same
> problem. Making the two of them work together in a same page seems to be
> a challenge. Not necessarily impossible, but challenging nonetheless.

So far I didn't see XForms as a system or framework, but as an advanced
technology over HTML forms. But using a server side XForms solution like
Orbeon Forms and trying to integrated it into an existing JSF application is
really challenging. And the submission problem may cause it to fail.  :(


- bitbyter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter,

On 5/16/07, BitByter <[hidden email]> wrote:
> Basically I'd like to specify an XForms submission like this:
>
> <xforms:submission action="#{myJsfHandler.processXformsSubmission}"
>       method="post" id="mySubmit" ref="instance('myInstance')" />

I quickly went  through the article, but I don't see anything like
that in there. All the submissions are done to a JSP file. So
essentially they take you to another page. Did I miss something?

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Alessandro,

Monday, May 21, 2007, 3:52:53 PM, you wrote:

> BitByter,

> On 5/16/07, BitByter <[hidden email]> wrote:
>> Basically I'd like to specify an XForms submission like this:
>>
>> <xforms:submission action="#{myJsfHandler.processXformsSubmission}"
>>       method="post" id="mySubmit" ref="instance('myInstance')" />

> I quickly went  through the article, but I don't see anything like
> that in there. All the submissions are done to a JSP file. So
> essentially they take you to another page. Did I miss something?

The interesting stuff about integrating JSF and XForms start at "Section 6"
at page 71. And the relevant part concerning the submission starts at
"Implementing the xforms-jsf:commandButton tag" at page 93.

There's also a demo application available for this article. It let's you
select a color, and forwards you to a page with the selected color after
submitting the selection.

Unfortunately I don't get it to work with Orbeon Forms. So I'm not sure if
this solution only works with clients that support XForms directly. Or does
it also work with server side XForms solutions?

- bitbyter






--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter wrote: I fear that they may be a clash between the way the Orbeon Forms XForms
engine communicates with the XForms server (through Ajax) and the way
JSF communicates with the server (How? By submitting an HTML form? If
so, which one?). And JSF needs to submit data to the server in order for
the JSF event handler to kick in.

But I don't quite understand how this is meant to work. The markup
produced by xforms-jsf:commandButton is just XForms markup that stores
some data into an XForms instance. But what happens after that, I don't
know: there is a missing step between this and the implementation of
decode() on the component mentioned in the article.

> There's also a demo application available for this article. It let's you
> select a color, and forwards you to a page with the selected color after
> submitting the selection.

But then you could do this directly with a regular XForms submission or
xforms:load, couldn't you?

> Unfortunately I don't get it to work with Orbeon Forms. So I'm not sure if
> this solution only works with clients that support XForms directly. Or does
> it also work with server side XForms solutions?

I don't see why in theory it couldn't work, but in practice the example
in the article may not be compatible with Orbeon Forms for a reason or
another. Maybe it's just a little bug, maybe it's a more fundamental
issue. But figuring this out is likely to take many hours.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter wrote:

 > Basically it should work. It's basically achieved by wrapping the
 > <xforms:submit> control into an own JSP <jsf:submitButton> component
 > which renders that <xforms:submit> control. This allows to register
 > an JSF event handler for the button.

So far so good, but this is also the point where I get lost ;-)

 > Unfortunately the sample application that comes with the article
 > does not work with Orbeon Forms. The custom JSF component renders
 > XForms tags/controls, which do not get transformed into XHTML by the
 > Orbeon Filter.  Any idea why this transformation into XHTML does not
 > work within the Orbeon XForms filter?

So you mean that the HTML page receives raw XForms for this component?
Can you paste the relevant part?

 > So far I didn't see XForms as a system or framework, but as an
 > advanced technology over HTML forms.

The same could be said of JSF...

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Erik,

Monday, May 21, 2007, 10:20:33 PM, you wrote:

> I fear that they may be a clash between the way the Orbeon Forms XForms
> engine communicates with the XForms server (through Ajax) and the way
> JSF communicates with the server (How? By submitting an HTML form? If
> so, which one?). And JSF needs to submit data to the server in order for
> the JSF event handler to kick in.

JSF uses the standard HTML form to communicate with the server. Usually an
JSF page only has one form that is being submitted. All form data is being
updated after successfull validation at the managed bean(s) to which each
form data is bound. Based on the the ID of the button, the JSF framework
knows which action handler to call to handle the request. The result of the
action handler is used for the navigation to the next JSP/JSF page.


> But I don't quite understand how this is meant to work. The markup
> produced by xforms-jsf:commandButton is just XForms markup that stores
> some data into an XForms instance. But what happens after that, I don't
> know: there is a missing step between this and the implementation of
> decode() on the component mentioned in the article.

The trick is seems to be to store the ID of the pressed button in the XForms
instance data. During the decode process of the JSF framework, the instance
data is parsed. So the JSF framework knows which button has been pressed and
can call the registered action handler.


>> There's also a demo application available for this article. It let's you
>> select a color, and forwards you to a page with the selected color after
>> submitting the selection.

> But then you could do this directly with a regular XForms submission or
> xforms:load, couldn't you?

But that doesn't allow you to use the JSF navigation rules (see
faces-config.xml). As far as I know you always need to specify the next JSP
page directly within the <xforms:submission> control.


>> Unfortunately I don't get it to work with Orbeon Forms. So I'm not sure if
>> this solution only works with clients that support XForms directly. Or does
>> it also work with server side XForms solutions?

> I don't see why in theory it couldn't work, but in practice the example
> in the article may not be compatible with Orbeon Forms for a reason or
> another. Maybe it's just a little bug, maybe it's a more fundamental
> issue. But figuring this out is likely to take many hours.

Basically the problem is that the custom JSF components in the example
renders XForms markup and I don't know why the Orbeon Forms filter does not
convert these XForms markup into XHTML+JavaScript? This is why I can't check
whether this way of JSF and XForms integration works with Orbeon Forms. :(

And by the way, did you know that IBM holds a patent on "Interleaving the
XForms processing model with Java server faces request processing"? Just
have a look at
http://www.freepatentsonline.com/20070033595.html?highlight=20070033595,200700335952&stemming=on.

- bitbyter




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Erik,

Monday, May 21, 2007, 10:25:54 PM, you wrote:

> BitByter wrote:

 >> Basically it should work. It's basically achieved by wrapping the
 >> <xforms:submit> control into an own JSP <jsf:submitButton> component
 >> which renders that <xforms:submit> control. This allows to register
 >> an JSF event handler for the button.

> So far so good, but this is also the point where I get lost ;-)

See a parallel post in this thread. Maybe it explains how the integration
basically works.


 >> Unfortunately the sample application that comes with the article
 >> does not work with Orbeon Forms. The custom JSF component renders
 >> XForms tags/controls, which do not get transformed into XHTML by the
 >> Orbeon Filter.  Any idea why this transformation into XHTML does not
 >> work within the Orbeon XForms filter?

> So you mean that the HTML page receives raw XForms for this component?
> Can you paste the relevant part?

I've attached the HTML file as it is generated by the cusom JSF component.
It contains XForms controls, which for some reason did not get converted to
(X)HTML by Orbeon Forms' servlet filter. Any idea why?


- bitbyter


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter,

On 5/22/07, BitByter <[hidden email]> wrote:
> I've attached the HTML file as it is generated by the cusom JSF component.
> It contains XForms controls, which for some reason did not get converted to
> (X)HTML by Orbeon Forms' servlet filter. Any idea why?

I think that the main problem is that this file is not XForms :). It
is not even well-formed XML. I attached a file where a fixed a few
things, but of course I can't test this as there is a submission to a
service I don't have here.

Can you change what is generated by the JSF components? Otherwise
maybe running JTidy plus some XSLT to change namespaces. This is not
trivial but should do the trick.

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Alex

Tuesday, May 22, 2007, 3:30:34 PM, you wrote:

> BitByter,

> On 5/22/07, BitByter <[hidden email]> wrote:
>> I've attached the HTML file as it is generated by the cusom JSF component.
>> It contains XForms controls, which for some reason did not get converted to
>> (X)HTML by Orbeon Forms' servlet filter. Any idea why?

> I think that the main problem is that this file is not XForms :). It
> is not even well-formed XML. I attached a file where a fixed a few
> things, but of course I can't test this as there is a submission to a
> service I don't have here.

The problem is that, whatever markup is being generated, it is not being
processed by the Orbeon Forms' servlet filter. Even if it is broken XML, OF
should raise an error if it is processing it. Shouldn't it?

The demo jsf/xforms integration application always does a submission to
itself. Which JSP is being rendered next, is always decided by the JSF
navigation rules. Thus when you deploy the demo application you also get the
service to which the submission takes place.  :)

> Can you change what is generated by the JSF components? Otherwise
> maybe running JTidy plus some XSLT to change namespaces. This is not
> trivial but should do the trick.

The source code is also shipped with the example, thus that it could be
adapted as/when needed.

- bitbyter






--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 5/22/07, BitByter <[hidden email]> wrote:
> The problem is that, whatever markup is being generated, it is not being
> processed by the Orbeon Forms' servlet filter. Even if it is broken XML, OF
> should raise an error if it is processing it. Shouldn't it?

This is a good point. I think that yes, it should be processed by the
filter in this case and generate an error.

> The demo jsf/xforms integration application always does a submission to
> itself. Which JSP is being rendered next, is always decided by the JSF
> navigation rules. Thus when you deploy the demo application you also get the
> service to which the submission takes place.  :)

I don't get that part. Could you elaborate on this?

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter wrote:

> And by the way, did you know that IBM holds a patent on "Interleaving the
> XForms processing model with Java server faces request processing"? Just
> have a look at
> http://www.freepatentsonline.com/20070033595.html?highlight=20070033595,200700335952&stemming=on.

A confirmation that the US patent system is completely insane. You would
expect the filing date for that to be April 1st.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Alessandro,

Tuesday, May 22, 2007, 10:35:23 PM, you wrote:

> This is a good point. I think that yes, it should be processed by the
> filter in this case and generate an error.

Any idea why it does not happen?


>> The demo jsf/xforms integration application always does a submission to
>> itself. Which JSP is being rendered next, is always decided by the JSF
>> navigation rules. Thus when you deploy the demo application you also get the
>> service to which the submission takes place.  :)

> I don't get that part. Could you elaborate on this?

Well, the point is, it doesn't matter which JSP/JSF page is requested via a
HTML form submission, as long as the request gets processed by the JSF
servlet. So for example, if the JSF servlet is mapped to all "*.faces" URLs,
you can put any, even non existing JSF pages in the "action" attribute of an
HTML form:

<form action="/this-page/does-not/exist.faces" method="put">

But this form tag usually is generated/rendered by the JSF framework, which
usually always put's the URL of the current page into the action attribute.

So the demo application should run. You just need to copy the servlet jars.

HTH

- bitbyter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 5/23/07, BitByter <[hidden email]> wrote:
> > This is a good point. I think that yes, it should be processed by the
> > filter in this case and generate an error.
>
> Any idea why it does not happen?

Do you have the ops-xforms-filter mapped to *.faces in web.xml, as
described in the page below?

http://www.orbeon.com/ops/doc/reference-xforms-java
But that should not be a problem. The XForms engine will then just
make the submission to the that page
(/this-page/does-not/exist.faces). The questions is: will that page be
able to handle what XForms sends? If it is a get with request
parameters, this shouldn't be a problem. But if you are doing a POST
or  PUT with an XML document, then this page must be able handle
receiving an XML document in the request body. But this would be
exactly the same if you are using a client-side implementation of
XForms.

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Alessandro,

Wednesday, May 23, 2007, 11:47:20 AM, you wrote:

> Do you have the ops-xforms-filter mapped to *.faces in web.xml, as
> described in the page below?
>
> http://www.orbeon.com/ops/doc/reference-xforms-java

No, the ops-xforms-filter is mapped to /xforms/* in my web.xml, and the
Demo.jsp page is located beneath this folder. All my other samples in the
same directory get processed by the filter.

I guess you don't have time left to check whether you can get that demo
application to run, respectively just get it to be processed by Orbeon
Forms (in a seperate deployment)?

> But that should not be a problem. The XForms engine will then just
> make the submission to the that page
> (/this-page/does-not/exist.faces). The questions is: will that page be
> able to handle what XForms sends? If it is a get with request
> parameters, this shouldn't be a problem. But if you are doing a POST
> or  PUT with an XML document, then this page must be able handle
> receiving an XML document in the request body. But this would be
> exactly the same if you are using a client-side implementation of
> XForms.

That demo application of the article expects an XML document with the
submission. It has implemented an XML parser to obtain the desired instance
data. I also think that it theoretically also should work with Orbeon Forms.
Unfortunately I'm currently under very big time pressure (deadline), so that
I  haven't  time to further investigate in this.  :(   But I think I will do
so in two or three weeks when I got some more time for research...  :)

- bitbyter





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

BitByter,

 > JSF uses the standard HTML form to communicate with the
 > server. Usually an JSF page only has one form that is being
 > submitted.

* Orbeon Forms also create a top-level <form> element.

* But contrary to JSF (unless Ajax is used in JSF), Orbeon Forms only
   rarely submit that form. In fact, it does it only when performing
   submissions with replace="all". In all other cases, it uses Ajax to
   communicate with the server.

Just pointing out that there are opporturnities for clashes between
the two systems.

 > All form data is being updated after successfull validation at the
 > managed bean(s) to which each form data is bound. Based on the the
 > ID of the button, the JSF framework knows which action handler to
 > call to handle the request. The result of the action handler is used
 > for the navigation to the next JSP/JSF page.

For a submission with replace="all", Orbeon Forms:

* First sends an Ajax request to the server.
* If everything goes well then submits the HTML <form>.
* This is intercepted by the XForms engine, which performs, from the
   server-side, the submission, and then returns a stream containing
   the resulting HTML (or other) page.

It seems to me that there is a conflict of interest between:

* XForms performing a submission as per the XForms spec.
* A JSF event handler kicking somewhere inbetween and deciding to what
   page to go next.

A rough guess is that a better solution would be to extend XForms with
a mechanism to call up JSF event handlers. But then, you have to be
careful with the handling of client-side HTML <form> elements, and
make sure the JSF form and the Orbeon Forms form don't conflict. This
would probably rquire changes in Orbeon Forms.

 > The trick is seems to be to store the ID of the pressed button in
 > the XForms instance data. During the decode process of the JSF
 > framework, the instance data is parsed. So the JSF framework knows
 > which button has been pressed and can call the registered action
 > handler.

That's understood. The problem is probably how to get the HTML form to
make to to the JSF framework.

 > Basically the problem is that the custom JSF components in the
 > example renders XForms markup and I don't know why the Orbeon Forms
 > filter does not convert these XForms markup into XHTML+JavaScript?
 > This is why I can't check whether this way of JSF and XForms
 > integration works with Orbeon Forms. :(

That's another good one to figure out ;-)

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 5/23/07, BitByter <[hidden email]> wrote:
> > Do you have the ops-xforms-filter mapped to *.faces in web.xml, as
> > described in the page below?
> >
> > http://www.orbeon.com/ops/doc/reference-xforms-java
>
> No, the ops-xforms-filter is mapped to /xforms/* in my web.xml, and the
> Demo.jsp page is located beneath this folder. All my other samples in the
> same directory get processed by the filter.

You mentioned earlier that the request goes to a page with the .faces
extension. So:

1) The request is made to /xforms/Demo.faces
2) The JSF servlet handles that request and runs Demo.jsp
3) The output is HTML + XForms
4) This output is processed by the Orbeon Filter

Is this what you expect to happen?

> I guess you don't have time left to check whether you can get that demo
> application to run, respectively just get it to be processed by Orbeon
> Forms (in a seperate deployment)?

That's right. There is only so much time we can spend on the list :).

Alex
--
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws