Re: [VOTE] Release Apache Johnzon-1.1.8

[Daniel Cunha]

+1

2018-06-27 12:46 GMT-03:00 Mark Struberg :

> Hi folks!
>
> I run the release steps for Johnzon-1.1.8.
>
> Note that we have a few things to solve still, but we can easily ship
> another release in the next few weeks.
> Just wanted to get something going, and we already have quite a few bugs
> fixed.
>
> The following tickets got resolved:
>
> Bug
>
> • [JOHNZON-164] - Non Spec conform handling of illegal json
> • [JOHNZON-165] - [JSONB] formatter sometimes ignored
> • [JOHNZON-168] - date format not respected
> • [JOHNZON-172] - JsonPatchBuilder issue for a partcuilar scenario
> • [JOHNZON-173] - JsonPointerImpl uses Json instead of the origin
> JsonProvider instance
> New Feature
>
> • [JOHNZON-163] - JSON-B JAX-RS provider should support
> ContextResolver to get a custom JSON-B instance
> • [JOHNZON-170] - add a polymorphic jsonb extension
> • [JOHNZON-171] - Add a module allowing to validate a JsonObject
> based on a JsonObject being a json schema
>
>
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachejohnzon-1028/
>
> The source release is in
> https://repository.apache.org/content/repositories/
> orgapachejohnzon-1028/org/apache/johnzon/johnzon/1.1.8/
> sha1 is e642768ab22296a9f14c6236da6f08c9b364c1fa
>
> Please VOTE
> [+1] yea, ship it
> [+0] meh, don't care
> [-1] nah because ${showstopper}
>
> The VOTE is open for 72h.
>
> txs and LieGrue,
> strub




-- 
Daniel "soro" Cunha
https://twitter.com/dvlc_

[jira] [Updated] (JOHNZON-105) add configurable support for MOVE in JsonPatchDiff

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOHNZON-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated JOHNZON-105:
--
Fix Version/s: (was: 1.1.8)
   1.1.9
   1.1.9

> add configurable support for MOVE in JsonPatchDiff
> --
>
> Key: JOHNZON-105
> URL: https://issues.apache.org/jira/browse/JOHNZON-105
> Project: Johnzon
>  Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Reinhard Sandtner
>Assignee: Reinhard Sandtner
>Priority: Major
> Fix For: 1.1.9
>
>
> JsonPatchDiff only supports the operations ADD, REMOVE and REPLACE
> we should add support to configure the calculation for MOVE too...
> the benefit would be that the JsonPatch-document would be smaller but the 
> processing time will increase
> imo we should make it configureable



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JOHNZON-161) JohnzonCDIExtension might create a mem leak

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOHNZON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated JOHNZON-161:
--
Fix Version/s: (was: 1.1.8)
   1.1.9

> JohnzonCDIExtension might create a mem leak
> ---
>
> Key: JOHNZON-161
> URL: https://issues.apache.org/jira/browse/JOHNZON-161
> Project: Johnzon
>  Issue Type: Task
>  Components: JSON-B
>Affects Versions: 1.1.7
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.1.9
>
>
> We use Json-B quite heavily and I experienced that there are tons of elements 
> in org.apache.johnzon.jsonb.cdi.JohnzonCdiExtension#jsonbs.
> Way too much for my gut feeling.
> The reason is that we do not use JsonBuilder as autocloseable is that it is 
> not required by the spec.
>  
> There is also not much documentation for JohnzonCdiExtension, so I can only 
> guess that it is for cleanly shutting down unused JsonbBuilder instances when 
> the app stops.
> We should probably only store WeakReferences.
>  
> I think the safest



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JOHNZON-141) support object deduplication in Maps

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOHNZON-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated JOHNZON-141:
--
Fix Version/s: (was: 1.1.8)
   1.1.9
   1.1.9

> support object deduplication in Maps
> 
>
> Key: JOHNZON-141
> URL: https://issues.apache.org/jira/browse/JOHNZON-141
> Project: Johnzon
>  Issue Type: Bug
>  Components: JSON-B, Mapper
>Affects Versions: 1.1.4
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.1.9
>
>
> We currently do not support deduplication of objects via JsonPonters if the 
> object is in a Map in the DTO. See JOHNZON-135.
> In MappingGeneratorImpl#writeMapBody(final Map object, final Adapter 
> itemConverter) needs a JsonPointerTracker parameter which gets filled 
> accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JOHNZON-146) Mapper json processing should use the order in the Json, not setters

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JOHNZON-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated JOHNZON-146:
--
Fix Version/s: (was: 1.1.8)
   1.1.9
   1.1.9

> Mapper json processing should use the order in the Json, not setters
> 
>
> Key: JOHNZON-146
> URL: https://issues.apache.org/jira/browse/JOHNZON-146
> Project: Johnzon
>  Issue Type: Bug
>  Components: JSON-B, Mapper
>Affects Versions: 1.1.5
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.1.9
>
>
> Currently we do a loop over all the getters and try to find the attribute in 
> the JSON.
> But for deduplicateObjects handling one might end up getting a JsonPointer 
> before the original object got processed. 
> This means that we should do it exactly the other way around: loop over the 
> json attributes and then use the setter accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: JSON-P & JSON-B jaxrs support mutually exclusive

[Raymond Auge]

On Wed, Jun 27, 2018 at 10:10 AM, Raymond Auge 
wrote:

> Sorry, I'm travelling this week so that's why I didn't act on this yet.
>
> What you can do temporarily to solve the issue is to explicitly widen the
> range of the imports on BOTH modules (noting that the JAXRS spec is
> actually backward compatible through major versions).
>
> e.g.
>
> Import-Package: javax.ws.rs.*;=version='[1.0,3)'
>

Import-Package: javax.ws.rs.*;version='[1.0,3)'


>
> That would be the shortest path to solving the mutual exclusive ranges.
>
> - Ray
>
> On Wed, Jun 27, 2018 at 9:59 AM, Mark Struberg 
> wrote:
>
>>  Raymond do you have a quick fix at hand?Would love to ship a Johnzon
>> release. Have a spare cycle today...
>> LieGrue,strub
>>
>> On Friday, 22 June 2018, 16:22:20 CEST, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>>  Hi Raymond,
>>
>> looks weird, jaxrs should be [1.0,) for everything, it is due to the
>> spec.version in the pom and does it mean we "just" have to explicitly set
>> it?
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> > high-performance>
>>
>>
>> Le ven. 22 juin 2018 à 15:21, Raymond Auge  a
>> écrit :
>>
>> > Hello all,
>> >
>> > I've found a small issue when trying to assemble a system from Johnzon's
>> > JAXRS providers.
>> >
>> > If you look at the package imports for johnzon-jaxrs:
>> >
>> >  javax.ws.rs{version=[2.0,3)}
>> >  javax.ws.rs.core  {version=[2.0,3)}
>> >  javax.ws.rs.ext{version=[2.0,3)}
>> >
>> > and those from johnzon-jsonb:
>> >
>> >  javax.ws.rs{version=[1.1,2),
>> > resolution:=optional}
>> >  javax.ws.rs.core  {version=[1.1,2),
>> > resolution:=optional}
>> >  javax.ws.rs.ext{version=[1.1,2),
>> > resolution:=optional}
>> >
>> > You'll notice that they have mutually exclusive version ranges, which
>> means
>> > they will never work together properly in the same OSGi runtime (at
>> least
>> > not in a _hack-free_ runtime.)
>> >
>> > So, will anyone mind if when the geronimo specs release with proper
>> > Portable Java Contracts (shortly hopefully) that I send a PR to apply
>> these
>> > to johnzon?
>> >
>> > I've created an issue for it
>> > https://issues.apache.org/jira/browse/JOHNZON-174
>> >
>> > Sincerely,
>> > --
>> > *Raymond Augé* 
>> >  (@rotty3000)
>> > Senior Software Architect *Liferay, Inc.* 
>> >  (@Liferay)
>> > Board Member & EEG Co-Chair, OSGi Alliance 
>> > (@OSGiAlliance)
>> >
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Apache Johnzon JsonbPropertyOrder behavior different from eclipse yasson.

[Mark Struberg]

 Btw Ravi, thanks for all the feedback on the various ASF projects - this is 
really very helpful!
Such things help us more than you think! It's precious information and is also 
a great way to contribute back to the community.

txs and LieGrue,strub

On Wednesday, 27 June 2018, 15:46:15 CEST, Mark Struberg 
 wrote:  
 
  If I look at the last comment from Dmitry it seems to me that Yasson now 
implements the spec behaviour, right?And that's exactly what we do as well 
right now, isn't?
Really looking forward to the TCKs which will soon be opened ;)
LieGrue,strub

On Wednesday, 27 June 2018, 15:42:22 CEST, Mark Struberg 
 wrote:  
 
  Oki, the both 'sources of truth' do differ.I think it's a rather pathological 
issue which not that many people will hit.Otoh it is still better to fix it.
Now let's ask ourselves what would you prefer?
A. apply the naming strategy and then sort?B. sort according to reflection info 
and then apply the naming?

I'd rather prefer A. Makes more sense to me. 
Even if that means that the apidoc and yasson is wrong.
Gonna trigger a discussion on the EG.
LieGrue,strub

    On Wednesday, 20 June 2018, 16:49:45 CEST, Romain Manni-Bucau 
 wrote:  
 
 spec will fix the javadoc anyway ;)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 20 juin 2018 à 16:48, Reinhard Sandtner 
a écrit :

> as a developer i would first look at the javadoc so maybe this would be a
> good default
> devs who read specs are very rare
>
> so +1 to align default johnzon behavior to javadoc (and yasson)
>
> > Am 20.06.2018 um 16:41 schrieb Romain Manni-Bucau  >:
> >
> > yes but our default will not be aligned on the spec and since the spec
> was
> > not clear
> > We can probably check if yasson is like us and make it to the spec. If we
> > were different we need a toggle, not sure of the default :s
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 20 juin 2018 à 16:32, Reinhard Sandtner <
> reinhard.sandt...@gmail.com>
> > a écrit :
> >
> >> hmm…. maybe we can make it configureable to not break existing apps?
> >>
> >>> Am 20.06.2018 um 15:52 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> seems it has been but it breaks us apparently which is a concern since
> we
> >>> should stay compatible.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le mer. 20 juin 2018 à 15:49, Reinhard Sandtner <
> >> reinhard.sandt...@gmail.com>
> >>> a écrit :
> >>>
>  hey,
> 
>  afaik the spec pdf and the javadoc-jar of JSR-367 are differing
> 
>  the pdf says to use renamed fields and the javadoc says to use the
> java
>  fields names :(
> 
>  so imo we need clarification in the spec
> 
>  lg
>  reini
> 
> 
> > Am 20.06.2018 um 15:02 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> > :
> >
> > Hi Ravi,
> >
> > Thanks to have sent the mail ;)
> >
> > for others: I asked Ravi to send this mail (he pinged on twitter)
> >> because
> > this can be a breaking change so not sure we want to directly impl it
> >> or
> > push it back to the spec. Any opinion welcomed.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
>  https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> 
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 20 juin 2018 à 15:01, Ravisankar Challa <
> ravisank...@gmail.com
> >>>
>  a
> > écrit :
> >
> >> Hi Devs,
> >>
> >> I got something form here
> >> https://github.com/eclipse-ee4j/yasson/issues/23
> >>
> >> It Says
> >>
> >> Properties names specified in @jsonbpropertyorder annotation must be
> >> the
> >> original names of properties as it’s specified in Java