RE: [wsrp-interop] WSRP event payloads with "simple" types

[Richard Jacob <richard.jacob@de.ibm.com>]

Just wanted to follow up on how we serialize
types in regard of the root element name.
What we do is the following:
- the root element qname becomes the
event name, which adhers to the WSRP spec, although as I said in the call
and in the posting from last year, I personally don't see much use to it
- on deserialization we examine the
type definition in the portlet.xml and invoke the JAXB deserializer with
that class
- we don't have a very compelling support
for event not declaring a type. basically it's a JAXB best effort to deserialize
that XML
But as you say, we would face the same
issues you describe here.

Mit freundlichen Grüßen / Kind regards
Richard Jacob
Team Lead Portal Standards & WCM development WSRP Standardization Lead
IBM Software Group, WPLC
WSS Websphere Portal Foundation Development 1
Phone:	+49-7031-16-3469	IBM Deutschland
E-Mail:	richard.jacob@de.ibm.com	Schoenaicher Str. 220
		71032 Boeblingen
		Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 

From:	"Nader Oteifa" <nader2@netunitysoftware.com>
To:	"'Kevin Frender'" <kevin.frender@oracle.com>
Cc:	<wsrp-interop@lists.oasis-open.org>
Date:	10/15/2009 10:19 PM
Subject:	RE: [wsrp-interop] WSRP event payloads with "simple" types

---

Kevin,

The event name serves as the name of the element under the <payload>
so you
have:

1) The element that needs to be read/written
2) Its XML type

To me, that is all you need to marshal either primitive types or classes.
It is up to portlet developers to decide what structure/type they wants
to
use to set event payload value: classes, primitive types, XML document
fragment. In your framework, you should provide easy options for all three.

As long as the event payload XML format is correct what does it matter
if
the portlet developer used a custom class versus a primitive type versus
an
XML DOM fragment?

Maybe I'm missing the point and worth a discussion by phone in the next
WSRP
meeting.  I've got questions for IBM re events so maybe we can have
a
meeting to discuss events a bit.

Nader

-----Original Message-----
From: Kevin Frender [mailto:kevin.frender@oracle.com]
Sent: Thursday, October 15, 2009 11:45 AM
To: Nader Oteifa
Cc: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] WSRP event payloads with "simple"
types

Hello Nader,

I may be misunderstanding your suggestion, but my original statement of
the problem wasn't entirely clear either.

Yes, I know that JAXB can be set up so that arbitrary objects can be 
marshalled and unmarshalled (as DOM elements), but the problem as I see
it is that for the simplest of data types explicitly supported by the 
JSR286 spec as event payloads, there is no obvious, inter-operable way
to marshal these event payloads so that they will be guaranteed to show
up in the receiving portlet as the same simple type that was sent.

For example, if portlet A sends an event:

eventResponse.setEvent(new QName("namespace", "localpart"),
"Simple 
String payload");

and portlet B receives this event, I would expect portlet B to be able
to do this:

Event event = eventRequest.getEvent();
String payload = (String)event.getValue();
 
-- and not need to do anything like this:

String payload = ((Element)event.getValue()).getTextContent();

The problem isn't that I don't know of any way at all to marshal the 
simple String payload into XML, or how to unmarshal that form back into
a String, but rather that I don't know how to distinguish between an 
event payload coming from another (third-party) WSRP producer or 
consumer that represents a marshalled simple payload type (like a 
String) versus an event payload that was deliberately configured by the
portlet developer to be marshalled into XML.  For example, if I get
an 
event payload in the WSRP event that looks like this:

<samplePayload>Simple String payload</samplePayload>

I could assume that this means I should return an Event object to the 
portlet developer whose payload is a java.lang.String object, as 
outlined in the sample above.  However, if the portlet developer for
event-sending portlet "C" actually created their own event payload
object and gave it a valid JAXB binding, such as:

@XmlRootElement
public class SamplePayload implements Serializable
{
    String value;
    public SamplePayload(String s)
    {
       value = s;
    }
}

eventResponse.setEvent(new QName("namespace", "localpart"),
new 
SamplePayload("Simple String payload"));

Then the developer actually intended for a "SamplePayload" object
to be 
sent, not a java.lang.String-- and a receiving portlet should probably
get an XML DOM element in the event payload instead of a simple 
java.lang.String object (assuming that the receiving portlet's WSRP 
implementation doesn't have a JAXB SamplePayload object configured). 

So my proposal would be a set of extension elements for containing only
the simplest of event payload values-- the simple types explicitly 
supported by the JSR286 specification-- so that various WSRP 
implementations could recognize those elements as containing a simple 
payload value (and ONLY a simple payload value).  I would propose
that 
arrays of simple values would not be supported, as they are not 
explicitly supported by the JSR286 spec as payload types, but arrays of
simple values can still be handled by JSR286 portlet developers by 
specifying their own JAXB bindings.

For example, we might define in the wsrp-extra namespace elements such
as:

<element name="stringPayload" type="xsd:string"/>
<element name="intPayload" type="xsd:int"/>
<element name="longPayload" type="xsd:long"/>
...

By being in the WSRP namespace (and being well-known elements) it would
be easy to distinguish these "simple" event payload types from
"complex" 
marshalled objects.  I can create such schema definitions for sending
simple payload types myself and put them in our proprietary namespace,
and they would work just fine as long as the events were not delivered
to a third-party WSRP producer, which wouldn't recognize them as 
intending to be "naked", simple values. 

So that is the point of my post- for at least the simplest of event 
payload types it seems like a WSRP-standard solution for encoding these
payload types would be beneficial for interop purposes.

   Kevin


Nader Oteifa wrote:
> Kevin,
>
> Any of these links of help?
>                  
>
https://jaxb.dev.java.net/tutorial/section_2_2_16_1-Elements-With-Any-Type.h
> tml#Elements%20With%20Any%20Type
>
>
https://jaxb.dev.java.net/tutorial/section_2_2_16_2-Another-Content-Tree-as-
> Element.html#Another%20Content%20Tree%20as%20Element
>
>
https://jaxb.dev.java.net/tutorial/section_6_2_7_6-Collecting-Unspecified-El
>
ements-XmlAnyElement.html#Collecting%20Unspecified%20Elements:%20XmlAnyEleme
> nt
>
> I think dealing with an extension is probably more complex than trying
to
> figure out how to make it work with primitive types without having
to
create
> a class. Do you expand payload to include all primitive types?  What
about
> arrays of primitive types? I don't even think namedStringArray should
be
in
> payload and even in the specification it appeared like it originally
was
not
> there.
>
> I think you'll have to take the "Any" XML element use it
as input to a new
> Unmarshaller but only when the value of the payload is requested with
the
> given type.  When marshalling, you'll need to have an extra parameter
to
> specify that a root should be created with same name as event or use
> overloaded methods.  Example:
>
>
> int x = myEvent.GetValue<int>(0); //parameter is default value
for type 
> myEvent.SetValue<int>(x, true); // parameter = true to create
an element
> with same name as event name
>
> or 
>
> int x = myEvent.GetValue(0); //overloaded methods for all primitive
types
> myEvent.SetValue(x); //these create the element with same name as
event
>
> or some variation on this theme.
>
> Nader
>
> -----Original Message-----
> From: Kevin Frender [mailto:kevin.frender@oracle.com]
> Sent: Wednesday, October 14, 2009 3:58 PM
> To: wsrp-interop@lists.oasis-open.org
> Subject: [wsrp-interop] WSRP event payloads with "simple"
types
>
> Hello all,
>
> For WSRP 2.0 events, the schema-supported event payload types are
a 
> NamedStringArray and "any" from a non-WSRP-types namespace.
 This was a 
> conscious decision at the time to not get into the details of 
> standardizing event payload encoding.
>
> For JSR286 (Java Portlet specification version 2.0) event payloads
can 
> have any JAXB-bindable object type, or any of the JAXB primitive types,
> which include very basic things like java.lang.String, java.util.Date,
> etc. which have obvious mappings to XML data types.  The JAXB
primitive 
> types don't have @XmlRootElement annotations however, so they can't
be 
> marshalled directly (by themselves) to XML.
>
> So if a portlet wanted to send an event with a simple String payload,
> JSR286 allows that, but there is no obvious way to represent that
in XML 
> as a WSRP event payload in a manner that other WSRP containers could
> recognize.
>
> In the interest of interoperability, I was wondering how everyone
> handles the binding of these "primitive" types when they
are used as an 
> event payload.  We were thinking of creating a simple XML element
for 
> holding these types inside the event payload, but that wouldn't work
too 
> well for WSRP interoperability, unless the WSRP committee came up
with a 
> standard schema and XML namespace to hold these "simple"
types.  So as a 
> second question, I was wondering if there was interest in creating
a 
> standard WSRP extension for handling these simple data types.
>
> Thanks,
>
>   Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>   


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php