On Thu, Aug 7, 2014 at 2:43 PM, Martijn Verburg <martijnverburg_at_gmail.com>
wrote:
> +1 to this - it needs a strawman doc for the various spec leads to discuss
> around. Great thinking BTW - it would be good to have a unifier for this.
>
I just published my article about this subject, it's at:
http://arjan-tijms.blogspot.com/2014/08/high-time-to-standardize-java-ee.html
Hopefully this will be a good starting point for further discussion.
Kind regards,
Arjan Tijms
> Cheers,
> Martijn
>
>
> On 7 August 2014 04:24, Reza Rahman <Reza.Rahman_at_oracle.com> wrote:
>
>> I think the best course of action is to write up a detailed proposal in
>> JIRA.
>>
>>
>> On 8/6/2014 10:58 PM, John D. Ament wrote:
>>
>>> Hi all,
>>>
>>> So in the last few days, i've pulled out what I would consider to be the
>>> last of my short hair dealing with type conversion in Java EE 7. In my
>>> project, I'm using JPA 2.1, JAX-RS 2.0 and WebSockets 1.0. In my use case,
>>> I have some POJOs that I pass around those three layers via JSON. In each
>>> of these, I have to worry about the type conversion requirements of each of
>>> them, specifically
>>>
>>> JPA leverages an AttributeConverter
>>> WebSockets use Encoder/Decoder's
>>> JAX-RS uses MessageBodyReader/Writer
>>>
>>> In two of these, it gets a little more confusing as I have to implement
>>> different interfaces for reading and writing. In total I need to implement
>>> 5 different interfaces, some of which support CDI injection and others that
>>> do not.
>>>
>>> In addition, if you look across the Java EE spectrum, we have additional
>>> ways in which type conversion is supported.
>>>
>>> JMS 2.0 added support for implicit body reading when getting a message
>>> and new ways to create messages from some POJOs.
>>> - We did not add support a serialization process other than reconfirming
>>> that ObjectMessage requires a Serializable object.
>>>
>>> JSF has a Converter interface
>>>
>>> I'm sure there are other use cases as well. I'd like to propose that
>>> the entire platform needs to consolidate down to a single way of converting
>>> objects, arbitrarily. Then allow each of these specs to build from that
>>> conversion going forward.
>>>
>>> I'm not sure the right course of action. Should this become a ticket
>>> for this spec? Does something like this require an enhancement
>>> specification by itself?
>>>
>>> Thanks,
>>>
>>> John
>>>
>>
>>
>