[jira] [Commented] (SLING-6666) Make Sling shiny

[Sandro Boehme (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954098#comment-15954098
 ] 

Sandro Boehme commented on SLING-:
--

I'm happy to see the ideas and improvements. SLING-3987 would also make Sling 
more shiny but I understand that it's a very big endeavor.

> Make Sling shiny
> 
>
> Key: SLING-
> URL: https://issues.apache.org/jira/browse/SLING-
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Oliver Lietz
> Attachments: Sling-4x.png
>
>
> https://cwiki.apache.org/confluence/display/SLING/Make+Sling+shiny



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSSION] Make Sling shiny - Basic CMS :: Sitebuilder, Google Cloud

[Sandro Boehme]

Hi,

personally I'm a lot into the idea of a frontend component based 
Sitebuilder like the one I created a poc for [1]. It is a simple concept 
that is very very powerful in my opinion. But it was JSP-based and I 
would rather like to have it Angular 2 based and would like to build up 
some more Angular 2 knowledge on a project before abstracting from 
Angular 2 :-). An other major problem I identified was, that I needed to 
use internal (non-API) code to get the script(s) for the page that is 
shown. But of course if that changes it wont work for me anymore.


To approach the Angular 2 project, I'm in the process of implementing a 
release process to the Google cloud for Sling. It's available for a 
single MongoDB but with a very rough and not always working 
documentation [2]. Since a few minutes it is also working for a MongoDB 
repl set. Documenting that and making some smaller adjustments is the 
next step to do. It would be fun to implement the MongoDB sharding as 
well but I won't need it in the near future so I have to pull myself up 
and care about the things I need :-).


Best,
Sandro

[1] - https://vimeo.com/140369433
[2] - https://github.com/sandroboehme/sample-launchpad

Am 30.03.17 um 23:06 schrieb Daniel Klco:

All,

It seems like creating a Basic Sling CMS is an exciting topic for a lot of
people and something a lot of people are interested in. I've also been
working on something on the side as well for this, and I was wondering if
others would see this potentially as a good base to start with.

The idea here is to be somewhat more developer focused (at least in the
initial version) and somewhat limited in functionality, but to provide
basic functionality for managing web content. It was based on Publick
initially, but I found that was more single-blog focused than I wanted so
it's significantly diverged.

If you have a sec, I'd appreciate feedback and thoughts on the project. I
haven't had a chance to really document much about how it should work and
it's not 100% functional (aka don't try to edit a page) but a lot of the
core functionality is there.

https://github.com/klcodanr/sling-cms

Thanks,
Dan

On Thu, Mar 30, 2017 at 3:45 PM, Chris Millar (JIRA) 
wrote:



[ https://issues.apache.org/jira/browse/SLING-?page=
com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel=15949678#comment-15949678 ]

Chris Millar commented on SLING-:
-

I'm probably speaking out of turn, but I have many thoughts on this.

First, I agree with what everyone is saying. Sling needs some presentation
and branding love. I would break this down into the following buckets:

# Docs - The information architecture of sling.apache.org needs to be
addressed... Raise your hand if you need quick access to Sling 5 docs in
the sidebar.
# Marketing and Polish - Basic things like the site not being responsive
or the logo being woefully out of date.
# Better On-boarding for Developers - Someone who wants to run java -jar
org.apache.sling.jar and start building something. How do you get from 8080
to 443?
# Better On-boarding for Contributors - Someone who wants to start working
with the guts of the project.
# Better On-boarding for Users - A basic CMS...

I really like the idea of everyone rallying around some _basic_ CMS for
Sling. I would argue it should be a pure SlingPostServlet / UserManager
solution over trying to make a tool like Composum or Slick bend to this
purpose. Composum is more of a CRX/DE Lite replacement and Slick is _way_
too opinionated about its UX.

I'll start adding some more thoughts to the wiki and will attach the logo
I updated for Sling a while ago. I'll also subscribe to the dev channel as
[~bdelacretaz] suggested.


Make Sling shiny


Key: SLING-
URL: https://issues.apache.org/jira/browse/SLING-
Project: Sling
 Issue Type: Task
 Components: General
   Reporter: Oliver Lietz

https://cwiki.apache.org/confluence/display/SLING/Make+Sling+shiny




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

actually, adding the latest version would be better

[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.8.6
com.fasterxml.jackson.core/jackson-core/2.8.6
com.fasterxml.jackson.core/jackson-annotations/2.8.6


On 4/3/2017 11:26 AM, Ruben Reusser wrote:

while you are at fixing the launchpad, would be good to add

[feature name=model-exporter]

# Add the dependencies on the Model exporter
[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.3.2
com.fasterxml.jackson.core/jackson-core/2.3.2
com.fasterxml.jackson.core/jackson-annotations/2.3.2

at the same time

Ruben

On 4/3/2017 11:24 AM, Oliver Lietz wrote:

On Monday 03 April 2017 20:16:49 Carsten Ziegeler wrote:

Just fixed the bug in the servlets post servlet, still remaining:

   ServerSideInstallerTest.noActiveResources:61 Active resources found:
[group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provi 


der, scheme=launchpad,
url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.prov 

ider-1.0.20.jar, type=bundle, error=null, state=INSTALL, 
version=1.0.20,

lastChange=-1, priority=50, digest=149124324
Some packages changed in Sightly recently. Using latest Sightly 
snapshots in

Launchpad fixed it for me.

Regards,
O.


Carsten
Carsten Ziegeler wrote


Ruben Reusser wrote


seems to me it's because Apache Sling Scripting HTL JavaScript Use
Provider does not activate anymore.

Yes, that seems to be one error.

But the file upload is currently not fully working either and 
that's due
to my "improvements" in that area. I just fixed one of the failing 
test

cases, looking into the other now.

Carsten

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

while you are at fixing the launchpad, would be good to add

[feature name=model-exporter]

# Add the dependencies on the Model exporter
[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.3.2
com.fasterxml.jackson.core/jackson-core/2.3.2
com.fasterxml.jackson.core/jackson-annotations/2.3.2

at the same time

Ruben

On 4/3/2017 11:24 AM, Oliver Lietz wrote:

On Monday 03 April 2017 20:16:49 Carsten Ziegeler wrote:

Just fixed the bug in the servlets post servlet, still remaining:

   ServerSideInstallerTest.noActiveResources:61 Active resources found:
[group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provi
der, scheme=launchpad,
url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.prov
ider-1.0.20.jar, type=bundle, error=null, state=INSTALL, version=1.0.20,
lastChange=-1, priority=50, digest=149124324

Some packages changed in Sightly recently. Using latest Sightly snapshots in
Launchpad fixed it for me.

Regards,
O.


Carsten
Carsten Ziegeler wrote


Ruben Reusser wrote


seems to me it's because Apache Sling Scripting HTL JavaScript Use
Provider does not activate anymore.

Yes, that seems to be one error.

But the file upload is currently not fully working either and that's due
to my "improvements" in that area. I just fixed one of the failing test
cases, looking into the other now.

Carsten

Re: struggling with sling-9 build and sling model exporter

[Oliver Lietz]

On Monday 03 April 2017 20:16:49 Carsten Ziegeler wrote:
> Just fixed the bug in the servlets post servlet, still remaining:
> 
>   ServerSideInstallerTest.noActiveResources:61 Active resources found:
> [group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provi
> der, scheme=launchpad,
> url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.prov
> ider-1.0.20.jar, type=bundle, error=null, state=INSTALL, version=1.0.20,
> lastChange=-1, priority=50, digest=149124324

Some packages changed in Sightly recently. Using latest Sightly snapshots in 
Launchpad fixed it for me.

Regards,
O.

> Carsten
> Carsten Ziegeler wrote
> 
> > Ruben Reusser wrote
> > 
> >> seems to me it's because Apache Sling Scripting HTL JavaScript Use
> >> Provider does not activate anymore.
> > 
> > Yes, that seems to be one error.
> > 
> > But the file upload is currently not fully working either and that's due
> > to my "improvements" in that area. I just fixed one of the failing test
> > cases, looking into the other now.
> > 
> > Carsten

Re: struggling with sling-9 build and sling model exporter

[Carsten Ziegeler]

Just fixed the bug in the servlets post servlet, still remaining:

  ServerSideInstallerTest.noActiveResources:61 Active resources found:
[group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provider,
scheme=launchpad,
url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.provider-1.0.20.jar,
type=bundle, error=null, state=INSTALL, version=1.0.20, lastChange=-1,
priority=50, digest=149124324

Carsten
Carsten Ziegeler wrote
> Ruben Reusser wrote
>> seems to me it's because Apache Sling Scripting HTL JavaScript Use
>> Provider does not activate anymore.
>>
> Yes, that seems to be one error.
> 
> But the file upload is currently not fully working either and that's due
> to my "improvements" in that area. I just fixed one of the failing test
> cases, looking into the other now.
> 
> Carsten
> 
>  
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: struggling with sling-9 build and sling model exporter

[Carsten Ziegeler]

Ruben Reusser wrote
> seems to me it's because Apache Sling Scripting HTL JavaScript Use
> Provider does not activate anymore.
> 
Yes, that seems to be one error.

But the file upload is currently not fully working either and that's due
to my "improvements" in that area. I just fixed one of the failing test
cases, looking into the other now.

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

seems to me it's because Apache Sling Scripting HTL JavaScript Use 
Provider does not activate anymore.


Ruben

On 4/3/2017 10:40 AM, Carsten Ziegeler wrote:

Daniel Klco wrote

Hm, I'm seeing that as well. I'm seeing failures
in org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest.
Checking into it now.


Hmm, this might be related to my recent changes to the post servlet. If
you need help, let me know

Regards
Carsten


In the meantime, you can skip the tests if you need to run a build (of
course this isn't a permanent solution)

Thanks,
Dan

On Mon, Apr 3, 2017 at 9:11 AM, Ruben Reusser  wrote:


Hi

I have been trying to successfully build trunk for the past couple of days
- it seems building launchpad/builder fails due to the tests. Is that just
me or a common problem?

I also noticed that the sling model exporter is missing from launchpad -
is that intentional?

thank you

Ruben




  

Re: struggling with sling-9 build and sling model exporter

[Carsten Ziegeler]

Daniel Klco wrote
> Hm, I'm seeing that as well. I'm seeing failures
> in org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest.
> Checking into it now.
> 
Hmm, this might be related to my recent changes to the post servlet. If
you need help, let me know

Regards
Carsten

> In the meantime, you can skip the tests if you need to run a build (of
> course this isn't a permanent solution)
> 
> Thanks,
> Dan
> 
> On Mon, Apr 3, 2017 at 9:11 AM, Ruben Reusser  wrote:
> 
>> Hi
>>
>> I have been trying to successfully build trunk for the past couple of days
>> - it seems building launchpad/builder fails due to the tests. Is that just
>> me or a common problem?
>>
>> I also noticed that the sling model exporter is missing from launchpad -
>> is that intentional?
>>
>> thank you
>>
>> Ruben
>>
>>
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-2696) Comply with project branding guidelines

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953699#comment-15953699
 ] 

Oliver Lietz commented on SLING-2696:
-

Thanks, [~auniverseaway]. Will take care in the next days.

> Comply with project branding guidelines
> ---
>
> Key: SLING-2696
> URL: https://issues.apache.org/jira/browse/SLING-2696
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Oliver Lietz
>Priority: Minor
> Attachments: Apache Sling Logo 2017.zip
>
>
> We need to comply with http://www.apache.org/foundation/marks/pmcs.html - the 
> current status is
> Logos and Graphics: TM missing from all Logos
> Project Website Basics: done
> Project Naming And Descriptions: done
> Website Navigation Links: done
> Trademark Attributions: done
> Project Metadata: done



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6767) Jackrabbit Usermanager: Allow to detect whether a POST request was treated by the default POST servlet or the jackrabbit.usermanager

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6767:
---
Description: Currently it is impossible to tell from the response whether a 
POST request has been answered by either the Default Sling POST servlet or the 
Jackrabbit Usermanager. Both the JSON and the HTML look exactly the same no 
matter, who answered. It should be possible to see from the client-side whether 
a request has been treated by one or the other.

> Jackrabbit Usermanager: Allow to detect whether a POST request was treated by 
> the default POST servlet or the jackrabbit.usermanager
> 
>
> Key: SLING-6767
> URL: https://issues.apache.org/jira/browse/SLING-6767
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Konrad Windszus
> Fix For: JCR Jackrabbit User Manager 2.2.8
>
>
> Currently it is impossible to tell from the response whether a POST request 
> has been answered by either the Default Sling POST servlet or the Jackrabbit 
> Usermanager. Both the JSON and the HTML look exactly the same no matter, who 
> answered. It should be possible to see from the client-side whether a request 
> has been treated by one or the other.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6767) Jackrabbit Usermanager: Allow to detect whether a POST request was treated by the default POST servlet or the jackrabbit.usermanager

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6767:
---
Affects Version/s: (was: JCR Jackrabbit User Manager 2.2.8)

> Jackrabbit Usermanager: Allow to detect whether a POST request was treated by 
> the default POST servlet or the jackrabbit.usermanager
> 
>
> Key: SLING-6767
> URL: https://issues.apache.org/jira/browse/SLING-6767
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Konrad Windszus
> Fix For: JCR Jackrabbit User Manager 2.2.8
>
>
> Currently it is impossible to tell from the response whether a POST request 
> has been answered by either the Default Sling POST servlet or the Jackrabbit 
> Usermanager. Both the JSON and the HTML look exactly the same no matter, who 
> answered. It should be possible to see from the client-side whether a request 
> has been treated by one or the other.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6767) Jackrabbit Usermanager: Allow to detect whether a POST request was treated by the default POST servlet or the jackrabbit.usermanager

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6767:
---
Fix Version/s: JCR Jackrabbit User Manager 2.2.8

> Jackrabbit Usermanager: Allow to detect whether a POST request was treated by 
> the default POST servlet or the jackrabbit.usermanager
> 
>
> Key: SLING-6767
> URL: https://issues.apache.org/jira/browse/SLING-6767
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Konrad Windszus
> Fix For: JCR Jackrabbit User Manager 2.2.8
>
>
> Currently it is impossible to tell from the response whether a POST request 
> has been answered by either the Default Sling POST servlet or the Jackrabbit 
> Usermanager. Both the JSON and the HTML look exactly the same no matter, who 
> answered. It should be possible to see from the client-side whether a request 
> has been treated by one or the other.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6747) User Manager: Support setting nested user properties

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6747.
--

> User Manager: Support setting nested user properties
> 
>
> Key: SLING-6747
> URL: https://issues.apache.org/jira/browse/SLING-6747
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Jackrabbit User Manager 2.2.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JCR Jackrabbit User Manager 2.2.6
>
>
> Currently if a property like {{preferences/myproperty}} is set to any value 
> through the POST request to e.g. /system/userManager/user/admin.update.html 
> the according property is not correctly set, but the response does also not 
> indicate any error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6451) Remove dependency to jcr.resource API

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6451.
--

> Remove dependency to jcr.resource API
> -
>
> Key: SLING-6451
> URL: https://issues.apache.org/jira/browse/SLING-6451
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Jackrabbit User Manager 2.2.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Jackrabbit User Manager 2.2.6
>
>
> As the jcr.resource API is deprecated we should replace it's usage with the 
> Resource API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6753) User Manager: Expose user's path as property

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6753.
--

> User Manager: Expose user's path as property
> 
>
> Key: SLING-6753
> URL: https://issues.apache.org/jira/browse/SLING-6753
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JCR Jackrabbit User Manager 2.2.6
>
>
> With the support of nested user properties (SLING-6747) the resource provider 
> will still only expose direct user properties through its {{ValueMap}}. This 
> is a limitation of the Jackrabbit Security API and its {{getPropertyNames()}} 
> method 
> (https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/api/security/user/Authorizable.html#getPropertyNames()).
>  To make it possible to read nested user properties through some other means, 
> it would be helpful to retrieve the underlying user path through the 
> `AuthorizableValueMap`, to then be able to access the nested properties via 
> regular means (i.e. Sling Resource API or JCR API).
> This is especially important since in Oak the user path is no longer 
> predictable 
> (http://jackrabbit.apache.org/oak/docs/security/user/authorizablenodename.html).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6767) Jackrabbit Usermanager: Allow to detect whether a POST request was treated by the default POST servlet or the jackrabbit.usermanager

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6767:
--

 Summary: Jackrabbit Usermanager: Allow to detect whether a POST 
request was treated by the default POST servlet or the jackrabbit.usermanager
 Key: SLING-6767
 URL: https://issues.apache.org/jira/browse/SLING-6767
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Jackrabbit User Manager 2.2.8
Reporter: Konrad Windszus






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-2696) Comply with project branding guidelines

[Chris Millar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951712#comment-15951712
 ] 

Chris Millar edited comment on SLING-2696 at 4/3/17 2:57 PM:
-

[~olli] [~bdelacretaz]

*Vector*
Sling Logo - All Styles.ai - Adobe Illustrator
Sling Logo - All Styles.pdf - Adobe PDF
Sling Logo - Close Crop.svg - SVG
Sling Logo - With URL.svg - SVG
Sling Logo.svg - SVG

*PNG*
Sling Logo - Close c...@1x.png
Sling Logo - Close c...@2x.png
Sling Logo - Close c...@3x.png
Sling Logo - With u...@1x.png
Sling Logo - With u...@2x.png
Sling Logo - With u...@3x.png
Sling l...@1x.png
Sling l...@2x.png
Sling l...@3x.png



was (Author: auniverseaway):
*Vector*
Sling Logo - All Styles.ai - Adobe Illustrator
Sling Logo - All Styles.pdf - Adobe PDF
Sling Logo - Close Crop.svg - SVG
Sling Logo - With URL.svg - SVG
Sling Logo.svg - SVG

*PNG*
Sling Logo - Close c...@1x.png
Sling Logo - Close c...@2x.png
Sling Logo - Close c...@3x.png
Sling Logo - With u...@1x.png
Sling Logo - With u...@2x.png
Sling Logo - With u...@3x.png
Sling l...@1x.png
Sling l...@2x.png
Sling l...@3x.png


> Comply with project branding guidelines
> ---
>
> Key: SLING-2696
> URL: https://issues.apache.org/jira/browse/SLING-2696
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Oliver Lietz
>Priority: Minor
> Attachments: Apache Sling Logo 2017.zip
>
>
> We need to comply with http://www.apache.org/foundation/marks/pmcs.html - the 
> current status is
> Logos and Graphics: TM missing from all Logos
> Project Website Basics: done
> Project Naming And Descriptions: done
> Website Navigation Links: done
> Trademark Attributions: done
> Project Metadata: done



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [JSON] Performance problems with new json library

[Karl Pauls]

You might want to check the date of the original message from Carsten :-).

regards,

Karl

On Mon, Apr 3, 2017 at 4:39 PM, Ian Boston  wrote:
> Did anyone consider gson?
>  Iirc it dosnt have dependencies, is similar in nature to Json.org and is
> the same or quicker.
>
> Best regards
> Ian
>
> On 3 Apr 2017 10:02 am, "Stefan Seifert"  wrote:
>
>> my opinion about jackson:
>>
>> pro:
>> - it's really very mature and proven in lots of projects
>> - in json performance rankings it's most times with the best ones
>> - it can be deployed in OSGi easily and uses semantic versioning
>> - i've used it in several projects and had no problems
>>
>> contra:
>> - it's quite fat from a deployment perspective, it think at least two
>> bundles are required (core+databind) making ~1.5 MB only for JSON
>> parsing/writing
>> - it does not implement javax.json interface, and does not seem to plan to
>> do this any time soon - we cannot decide to switch to another
>> implementation later
>> - we already invested a good deal of time in javax.json migration
>>
>> i'm wondering if the reason of the performance degradation is:
>> a) poor performance in the johnzon impl itself
>> b) poor usage of the javax.json API on our side in the GET servlet
>> c) design problems with the javax.json interface which makes it
>> problematic to get good performance
>>
>> in performance ranking to be found on the internet johnzon was not tested
>> in most times because it is quite new. i'm not sure how much time the
>> johnzon community has invested in performance optimization yet, and if
>> improvements are expected here any time soon (our patch for making the
>> deployment OSGi compatible is still pending due to lack of time for
>> reviewing/testing it).
>>
>> stefan
>>
>>
>> >-Original Message-
>> >From: Carsten Ziegeler [mailto:cziege...@apache.org]
>> >Sent: Saturday, April 1, 2017 8:55 AM
>> >To: Sling Developers
>> >Subject: [JSON] Performance problems with new json library
>> >
>> >Hi,
>> >
>> >as you all know we had to replace the usage of the org.json library due
>> >to it's license (see SLING-6679). We decided to go with Apache Johnzon
>> >as the replacement.
>> >
>> >Now as most of the work is done I did some performance testing, mainly
>> >of the json get servlet, rendering a 2k json response requested by 50
>> >clients in parallel. Unfortunately it seems that this library is causing
>> >a significant performance degradation. I noticed json responses to be
>> >between 15% and 20% slower. I can't explain what is causing this as all
>> >we do is simply write out json.
>> >
>> >So I went ahead and did a quick test by replacing johnson with jackson
>> >and interestingly, this one is in the same range as org.json, slightly
>> >faster even.
>> >
>> >Given this, I seriously think we should not use johnson but switch to
>> >jackson. As we have identified all the places, replacing is not one of
>> >the nicest tasks, but it should be doable within a short time frame.
>> >
>> >WDYT?
>> >
>> >Regards
>> >Carsten
>> >--
>> >Carsten Ziegeler
>> >Adobe Research Switzerland
>> >cziege...@apache.org
>> >
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

RE: [JSON] Performance problems with new json library

[Ian Boston]

Did anyone consider gson?
 Iirc it dosnt have dependencies, is similar in nature to Json.org and is
the same or quicker.

Best regards
Ian

On 3 Apr 2017 10:02 am, "Stefan Seifert"  wrote:

> my opinion about jackson:
>
> pro:
> - it's really very mature and proven in lots of projects
> - in json performance rankings it's most times with the best ones
> - it can be deployed in OSGi easily and uses semantic versioning
> - i've used it in several projects and had no problems
>
> contra:
> - it's quite fat from a deployment perspective, it think at least two
> bundles are required (core+databind) making ~1.5 MB only for JSON
> parsing/writing
> - it does not implement javax.json interface, and does not seem to plan to
> do this any time soon - we cannot decide to switch to another
> implementation later
> - we already invested a good deal of time in javax.json migration
>
> i'm wondering if the reason of the performance degradation is:
> a) poor performance in the johnzon impl itself
> b) poor usage of the javax.json API on our side in the GET servlet
> c) design problems with the javax.json interface which makes it
> problematic to get good performance
>
> in performance ranking to be found on the internet johnzon was not tested
> in most times because it is quite new. i'm not sure how much time the
> johnzon community has invested in performance optimization yet, and if
> improvements are expected here any time soon (our patch for making the
> deployment OSGi compatible is still pending due to lack of time for
> reviewing/testing it).
>
> stefan
>
>
> >-Original Message-
> >From: Carsten Ziegeler [mailto:cziege...@apache.org]
> >Sent: Saturday, April 1, 2017 8:55 AM
> >To: Sling Developers
> >Subject: [JSON] Performance problems with new json library
> >
> >Hi,
> >
> >as you all know we had to replace the usage of the org.json library due
> >to it's license (see SLING-6679). We decided to go with Apache Johnzon
> >as the replacement.
> >
> >Now as most of the work is done I did some performance testing, mainly
> >of the json get servlet, rendering a 2k json response requested by 50
> >clients in parallel. Unfortunately it seems that this library is causing
> >a significant performance degradation. I noticed json responses to be
> >between 15% and 20% slower. I can't explain what is causing this as all
> >we do is simply write out json.
> >
> >So I went ahead and did a quick test by replacing johnson with jackson
> >and interestingly, this one is in the same range as org.json, slightly
> >faster even.
> >
> >Given this, I seriously think we should not use johnson but switch to
> >jackson. As we have identified all the places, replacing is not one of
> >the nicest tasks, but it should be doable within a short time frame.
> >
> >WDYT?
> >
> >Regards
> >Carsten
> >--
> >Carsten Ziegeler
> >Adobe Research Switzerland
> >cziege...@apache.org
> >
>
>

[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953564#comment-15953564
 ] 

Felix Meschberger commented on SLING-6702:
--

bq. prevent it from getting unregistering

[~chetanm] This is just not possible: Consider the bundle is stopped and 
restarted.

bq. Note that currently MetricsServiceImpl is not using any OSGi config and has 
no required dependency on any other service.

As you say currently. When you add it and forget to abide by the expectation of 
MetricsServiceFactory, you get a failure.

Your call to ignore this warning, but it is an existing fragility.

> Make MetricsService accessible as easily as a Logger
> 
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Commons Metrics 1.2.2
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the 
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module, 
> usable like
> {code}
>   MetricsService ms = 
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module, 
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: struggling with sling-9 build and sling model exporter

[Daniel Klco]

Hm, I'm seeing that as well. I'm seeing failures
in org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest.
Checking into it now.

In the meantime, you can skip the tests if you need to run a build (of
course this isn't a permanent solution)

Thanks,
Dan

On Mon, Apr 3, 2017 at 9:11 AM, Ruben Reusser  wrote:

> Hi
>
> I have been trying to successfully build trunk for the past couple of days
> - it seems building launchpad/builder fails due to the tests. Is that just
> me or a common problem?
>
> I also noticed that the sling model exporter is missing from launchpad -
> is that intentional?
>
> thank you
>
> Ruben
>
>

struggling with sling-9 build and sling model exporter

[Ruben Reusser]

Hi

I have been trying to successfully build trunk for the past couple of 
days - it seems building launchpad/builder fails due to the tests. Is 
that just me or a common problem?


I also noticed that the sling model exporter is missing from launchpad - 
is that intentional?


thank you

Ruben

[jira] [Commented] (SLING-6685) Replace commons.json usage in org.apache.sling.xss

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953320#comment-15953320
 ] 

Karl Pauls commented on SLING-6685:
---

Fine by me. If somebody depends on the JSONUtil  it requires a rewrite anyways 
and if not it will have no impact. What do other think (we might have to take 
this to the dev list)?

> Replace commons.json usage in org.apache.sling.xss
> --
>
> Key: SLING-6685
> URL: https://issues.apache.org/jira/browse/SLING-6685
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.18
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: XSS Protection API 1.0.20
>
> Attachments: SLING-6685-2.patch, SLING-6685.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6685) Replace commons.json usage in org.apache.sling.xss

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953257#comment-15953257
 ] 

Stefan Seifert commented on SLING-6685:
---

bq. Additionally, I fixed some javadoc and changed the api version to 2.0.0 as 
this is a breaking change (unfortunately, the api is leaking the JSONObject).
perhaps we should move the JsonUtil class into a separate package? it was a bad 
idea to include a dependency to a JSON API in the first place, but if we want 
to provide such functionality we should not break everything else if we need to 
switch to another JSON implementation later again.

now it's still time before releasing the 2.0.0 package version.

> Replace commons.json usage in org.apache.sling.xss
> --
>
> Key: SLING-6685
> URL: https://issues.apache.org/jira/browse/SLING-6685
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.18
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: XSS Protection API 1.0.20
>
> Attachments: SLING-6685-2.patch, SLING-6685.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.18

[Robert Munteanu]

On Sat, 2017-04-01 at 07:53 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: Javadoc generation

[Robert Munteanu]

The fix you added looks good to me, thanks!

Robert

On Mon, 2017-04-03 at 10:41 +0200, Konrad Windszus wrote:
> Hi Robert,
> thanks for the info. I think that script needs to be extended,
> because currently this only considers the dependencies from
> slingfeature.txt (i.e. bundles available at run time). In addition at
> least the compile time annotations from https://github.com/apache/sli
> ng/blob/trunk/tooling/maven/adapter-annotations should be included as
> well. I will try to come up with a fix for that script.
> Thanks,
> Konrad
> > On 3 Apr 2017, at 10:09, Robert Munteanu 
> > wrote:
> > 
> > Hi Konrad,
> > 
> > On Mon, 2017-04-03 at 10:01 +0200, Konrad Windszus wrote:
> > > I am currently looking for a documentation how the javadoc for a
> > > Sling release is generated. The documentation at
> > > https://sling.apache.org/documentation.html#the-javadoc seems to
> > > be
> > > outdated. I want to make sure that for Sling9 we include some
> > > more
> > > packages here: https://issues.apache.org/jira/browse/SLING-6766.
> > 
> > The tooling is present at
> > 
> >  http://svn.apache.org/repos/asf/sling/trunk/tooling/release/
> > 
> > Take a look at the generate_javadoc_for_release.sh script.
> > 
> > Robert
> 
> 

Re: [JSON] Performance problems with new json library

[Robert Munteanu]

On Mon, 2017-04-03 at 11:12 +0200, Karl Pauls wrote:
> On Mon, Apr 3, 2017 at 9:59 AM, Robert Munteanu 
> wrote:
> > On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
> > > I think we should just switch to xml and be done with it.
> > 
> > I don't think we can drop JSON in the foreseeable future. Clients
> > may
> > choose to switch to XML, but we need to offer comparable
> > performance
> > for those using JSON.
> 
> Not on the first of April. We are free to drop whatever functionality
> on that date ;-)


Indeed we are :-)

Robert

> 
> regards,
> 
> Karl
> 
> > Robert
> > 
> > > 
> > > regards,
> > > 
> > > Karl
> > > 
> > > On Saturday, April 1, 2017, Carsten Ziegeler  > > g>
> > > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > as you all know we had to replace the usage of the org.json
> > > > library
> > > > due
> > > > to it's license (see SLING-6679). We decided to go with Apache
> > > > Johnzon
> > > > as the replacement.
> > > > 
> > > > Now as most of the work is done I did some performance testing,
> > > > mainly
> > > > of the json get servlet, rendering a 2k json response requested
> > > > by
> > > > 50
> > > > clients in parallel. Unfortunately it seems that this library
> > > > is
> > > > causing
> > > > a significant performance degradation. I noticed json responses
> > > > to
> > > > be
> > > > between 15% and 20% slower. I can't explain what is causing
> > > > this as
> > > > all
> > > > we do is simply write out json.
> > > > 
> > > > So I went ahead and did a quick test by replacing johnson with
> > > > jackson
> > > > and interestingly, this one is in the same range as org.json,
> > > > slightly
> > > > faster even.
> > > > 
> > > > Given this, I seriously think we should not use johnson but
> > > > switch
> > > > to
> > > > jackson. As we have identified all the places, replacing is not
> > > > one
> > > > of
> > > > the nicest tasks, but it should be doable within a short time
> > > > frame.
> > > > 
> > > > WDYT?
> > > > 
> > > > Regards
> > > > Carsten
> > > > --
> > > > Carsten Ziegeler
> > > > Adobe Research Switzerland
> > > > cziege...@apache.org 
> > > > 
> > > > 
> > > 
> > > 
> 
> 
> 

[jira] [Assigned] (SLING-6740) HTL Blog Sample

[Radu Cotescu (JIRA)]

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

Radu Cotescu reassigned SLING-6740:
---

Assignee: Radu Cotescu

> HTL Blog Sample
> ---
>
> Key: SLING-6740
> URL: https://issues.apache.org/jira/browse/SLING-6740
> Project: Sling
>  Issue Type: Improvement
>  Components: Samples
>Reporter: Chris Millar
>Assignee: Radu Cotescu
>Priority: Minor
>
> The ESP blog sample is a little long in tooth. It should either be updated or 
> replaced by an HTL blog sample.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6740) HTL Blog Sample

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6740:

Component/s: Samples

> HTL Blog Sample
> ---
>
> Key: SLING-6740
> URL: https://issues.apache.org/jira/browse/SLING-6740
> Project: Sling
>  Issue Type: Improvement
>  Components: Samples
>Reporter: Chris Millar
>Assignee: Radu Cotescu
>Priority: Minor
>
> The ESP blog sample is a little long in tooth. It should either be updated or 
> replaced by an HTL blog sample.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [JSON] Performance problems with new json library

[Karl Pauls]

On Mon, Apr 3, 2017 at 9:59 AM, Robert Munteanu  wrote:
> On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
>> I think we should just switch to xml and be done with it.
>
> I don't think we can drop JSON in the foreseeable future. Clients may
> choose to switch to XML, but we need to offer comparable performance
> for those using JSON.

Not on the first of April. We are free to drop whatever functionality
on that date ;-)

regards,

Karl

> Robert
>
>>
>> regards,
>>
>> Karl
>>
>> On Saturday, April 1, 2017, Carsten Ziegeler 
>> wrote:
>>
>> > Hi,
>> >
>> > as you all know we had to replace the usage of the org.json library
>> > due
>> > to it's license (see SLING-6679). We decided to go with Apache
>> > Johnzon
>> > as the replacement.
>> >
>> > Now as most of the work is done I did some performance testing,
>> > mainly
>> > of the json get servlet, rendering a 2k json response requested by
>> > 50
>> > clients in parallel. Unfortunately it seems that this library is
>> > causing
>> > a significant performance degradation. I noticed json responses to
>> > be
>> > between 15% and 20% slower. I can't explain what is causing this as
>> > all
>> > we do is simply write out json.
>> >
>> > So I went ahead and did a quick test by replacing johnson with
>> > jackson
>> > and interestingly, this one is in the same range as org.json,
>> > slightly
>> > faster even.
>> >
>> > Given this, I seriously think we should not use johnson but switch
>> > to
>> > jackson. As we have identified all the places, replacing is not one
>> > of
>> > the nicest tasks, but it should be doable within a short time
>> > frame.
>> >
>> > WDYT?
>> >
>> > Regards
>> > Carsten
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org 
>> >
>> >
>>
>>
>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Resolved] (SLING-6766) Javadoc: Include package org.apache.sling.adapter.annotations in the Sling javadocs

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6766.

Resolution: Fixed

Fixed in [r1789927|https://svn.apache.org/r1789927].

> Javadoc: Include package org.apache.sling.adapter.annotations in the Sling 
> javadocs
> ---
>
> Key: SLING-6766
> URL: https://issues.apache.org/jira/browse/SLING-6766
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons, Site
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently the javadocs at https://sling.apache.org/apidocs/sling8/ do not 
> include the package {{org.apache.sling.adapter.annotations}} (being added 
> with SLING-2313).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6766) Javadoc: Include package org.apache.sling.adapter.annotations in the Sling javadocs

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-6766:
--

Assignee: Konrad Windszus

> Javadoc: Include package org.apache.sling.adapter.annotations in the Sling 
> javadocs
> ---
>
> Key: SLING-6766
> URL: https://issues.apache.org/jira/browse/SLING-6766
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons, Site
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently the javadocs at https://sling.apache.org/apidocs/sling8/ do not 
> include the package {{org.apache.sling.adapter.annotations}} (being added 
> with SLING-2313).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [JSON] Performance problems with new json library

[Carsten Ziegeler]

It's very unfortunate that the 1st of April was on a Saturday...

Carsten

Carsten Ziegeler wrote
> Hi,
> 
> as you all know we had to replace the usage of the org.json library due
> to it's license (see SLING-6679). We decided to go with Apache Johnzon
> as the replacement.
> 
> Now as most of the work is done I did some performance testing, mainly
> of the json get servlet, rendering a 2k json response requested by 50
> clients in parallel. Unfortunately it seems that this library is causing
> a significant performance degradation. I noticed json responses to be
> between 15% and 20% slower. I can't explain what is causing this as all
> we do is simply write out json.
> 
> So I went ahead and did a quick test by replacing johnson with jackson
> and interestingly, this one is in the same range as org.json, slightly
> faster even.
> 
> Given this, I seriously think we should not use johnson but switch to
> jackson. As we have identified all the places, replacing is not one of
> the nicest tasks, but it should be doable within a short time frame.
> 
> WDYT?
> 
> Regards
> Carsten
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-6766) Javadoc: Include package org.apache.sling.adapter.annotations in the Sling javadocs

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953140#comment-15953140
 ] 

Konrad Windszus commented on SLING-6766:


The script {{generate_javadoc_for_release.sh}} at 
{{http://svn.apache.org/repos/asf/sling/trunk/tooling/release/}} must be 
extended. Compare with discussion at 
http://www.mail-archive.com/dev@sling.apache.org/msg66606.html.

> Javadoc: Include package org.apache.sling.adapter.annotations in the Sling 
> javadocs
> ---
>
> Key: SLING-6766
> URL: https://issues.apache.org/jira/browse/SLING-6766
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons, Site
>Reporter: Konrad Windszus
>
> Currently the javadocs at https://sling.apache.org/apidocs/sling8/ do not 
> include the package {{org.apache.sling.adapter.annotations}} (being added 
> with SLING-2313).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Javadoc generation

[Konrad Windszus]

Hi Robert,
thanks for the info. I think that script needs to be extended, because 
currently this only considers the dependencies from slingfeature.txt (i.e. 
bundles available at run time). In addition at least the compile time 
annotations from 
https://github.com/apache/sling/blob/trunk/tooling/maven/adapter-annotations 
should be included as well. I will try to come up with a fix for that script.
Thanks,
Konrad
> On 3 Apr 2017, at 10:09, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Mon, 2017-04-03 at 10:01 +0200, Konrad Windszus wrote:
>> I am currently looking for a documentation how the javadoc for a
>> Sling release is generated. The documentation at
>> https://sling.apache.org/documentation.html#the-javadoc seems to be
>> outdated. I want to make sure that for Sling9 we include some more
>> packages here: https://issues.apache.org/jira/browse/SLING-6766.
> 
> The tooling is present at
> 
>  http://svn.apache.org/repos/asf/sling/trunk/tooling/release/
> 
> Take a look at the generate_javadoc_for_release.sh script.
> 
> Robert

Re: Javadoc generation

[Robert Munteanu]

Hi Konrad,

On Mon, 2017-04-03 at 10:01 +0200, Konrad Windszus wrote:
> I am currently looking for a documentation how the javadoc for a
> Sling release is generated. The documentation at
> https://sling.apache.org/documentation.html#the-javadoc seems to be
> outdated. I want to make sure that for Sling9 we include some more
> packages here: https://issues.apache.org/jira/browse/SLING-6766.

The tooling is present at

  http://svn.apache.org/repos/asf/sling/trunk/tooling/release/

Take a look at the generate_javadoc_for_release.sh script.

Robert

[RESULT] [VOTE] Release Apache Sling Jackrabbit User Manager version 2.2.6

[Konrad Windszus]

Hi, 
The vote has passed with the following result : 
+1 (binding): Dan Klco, Oliver Lietz, Stefan Seifert

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.
Thanks for voting,
Konrad

RE: [JSON] Performance problems with new json library

[Stefan Seifert]

my opinion about jackson:

pro:
- it's really very mature and proven in lots of projects
- in json performance rankings it's most times with the best ones
- it can be deployed in OSGi easily and uses semantic versioning
- i've used it in several projects and had no problems

contra:
- it's quite fat from a deployment perspective, it think at least two bundles 
are required (core+databind) making ~1.5 MB only for JSON parsing/writing
- it does not implement javax.json interface, and does not seem to plan to do 
this any time soon - we cannot decide to switch to another implementation later
- we already invested a good deal of time in javax.json migration

i'm wondering if the reason of the performance degradation is:
a) poor performance in the johnzon impl itself
b) poor usage of the javax.json API on our side in the GET servlet
c) design problems with the javax.json interface which makes it problematic to 
get good performance

in performance ranking to be found on the internet johnzon was not tested in 
most times because it is quite new. i'm not sure how much time the johnzon 
community has invested in performance optimization yet, and if improvements are 
expected here any time soon (our patch for making the deployment OSGi 
compatible is still pending due to lack of time for reviewing/testing it).

stefan


>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Saturday, April 1, 2017 8:55 AM
>To: Sling Developers
>Subject: [JSON] Performance problems with new json library
>
>Hi,
>
>as you all know we had to replace the usage of the org.json library due
>to it's license (see SLING-6679). We decided to go with Apache Johnzon
>as the replacement.
>
>Now as most of the work is done I did some performance testing, mainly
>of the json get servlet, rendering a 2k json response requested by 50
>clients in parallel. Unfortunately it seems that this library is causing
>a significant performance degradation. I noticed json responses to be
>between 15% and 20% slower. I can't explain what is causing this as all
>we do is simply write out json.
>
>So I went ahead and did a quick test by replacing johnson with jackson
>and interestingly, this one is in the same range as org.json, slightly
>faster even.
>
>Given this, I seriously think we should not use johnson but switch to
>jackson. As we have identified all the places, replacing is not one of
>the nicest tasks, but it should be doable within a short time frame.
>
>WDYT?
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org
>

Javadoc generation

[Konrad Windszus]

I am currently looking for a documentation how the javadoc for a Sling release 
is generated. The documentation at 
https://sling.apache.org/documentation.html#the-javadoc seems to be outdated. I 
want to make sure that for Sling9 we include some more packages here: 
https://issues.apache.org/jira/browse/SLING-6766.
Thanks for any pointers.
Konrad

Re: [JSON] Performance problems with new json library

[Robert Munteanu]

On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
> I think we should just switch to xml and be done with it.

I don't think we can drop JSON in the foreseeable future. Clients may
choose to switch to XML, but we need to offer comparable performance
for those using JSON.

Robert

> 
> regards,
> 
> Karl
> 
> On Saturday, April 1, 2017, Carsten Ziegeler 
> wrote:
> 
> > Hi,
> > 
> > as you all know we had to replace the usage of the org.json library
> > due
> > to it's license (see SLING-6679). We decided to go with Apache
> > Johnzon
> > as the replacement.
> > 
> > Now as most of the work is done I did some performance testing,
> > mainly
> > of the json get servlet, rendering a 2k json response requested by
> > 50
> > clients in parallel. Unfortunately it seems that this library is
> > causing
> > a significant performance degradation. I noticed json responses to
> > be
> > between 15% and 20% slower. I can't explain what is causing this as
> > all
> > we do is simply write out json.
> > 
> > So I went ahead and did a quick test by replacing johnson with
> > jackson
> > and interestingly, this one is in the same range as org.json,
> > slightly
> > faster even.
> > 
> > Given this, I seriously think we should not use johnson but switch
> > to
> > jackson. As we have identified all the places, replacing is not one
> > of
> > the nicest tasks, but it should be doable within a short time
> > frame.
> > 
> > WDYT?
> > 
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org 
> > 
> > 
> 
> 

Re: [JSON] Performance problems with new json library

[Robert Munteanu]

On Sat, 2017-04-01 at 08:55 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> as you all know we had to replace the usage of the org.json library
> due
> to it's license (see SLING-6679). We decided to go with Apache
> Johnzon
> as the replacement.
> 
> Now as most of the work is done I did some performance testing,
> mainly
> of the json get servlet, rendering a 2k json response requested by 50
> clients in parallel. Unfortunately it seems that this library is
> causing
> a significant performance degradation. I noticed json responses to be
> between 15% and 20% slower. I can't explain what is causing this as
> all
> we do is simply write out json.

Would it be worth capturing a profiler snapshot and sending it to the
Johnzon project?

Robert

> 
> So I went ahead and did a quick test by replacing johnson with
> jackson
> and interestingly, this one is in the same range as org.json,
> slightly
> faster even.
> 
> Given this, I seriously think we should not use johnson but switch to
> jackson. As we have identified all the places, replacing is not one
> of
> the nicest tasks, but it should be doable within a short time frame.
> 
> WDYT?
> 
> Regards
> Carsten

[jira] [Created] (SLING-6766) Javadoc: Include package org.apache.sling.adapter.annotations in the Sling javadocs

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6766:
--

 Summary: Javadoc: Include package 
org.apache.sling.adapter.annotations in the Sling javadocs
 Key: SLING-6766
 URL: https://issues.apache.org/jira/browse/SLING-6766
 Project: Sling
  Issue Type: Improvement
  Components: Commons, Site
Reporter: Konrad Windszus


Currently the javadocs at https://sling.apache.org/apidocs/sling8/ do not 
include the package {{org.apache.sling.adapter.annotations}} (being added with 
SLING-2313).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)