[jira] [Commented] (SLING-3374) Overlay sendRedirect to get relative Location header
[ https://issues.apache.org/jira/browse/SLING-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891913#comment-13891913 ] Bertrand Delacretaz commented on SLING-3374: Can you provide a scenario or automated test to reproduce the issue? IIUC from an offline discussion this happens when running Sling on specific servlet engines. There's a number of tests under [1] which verify the Location header in responses, I assume some of them should show the problem if you run them in a problematic environment. [1] https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests Overlay sendRedirect to get relative Location header Key: SLING-3374 URL: https://issues.apache.org/jira/browse/SLING-3374 Project: Sling Issue Type: Bug Reporter: Laurie byrum Recently, Location headers returned from redirects started being absolute instead of relative. We should try to decorate this in sling. Can we replace the sendRedirect with a set-header set-status combination in sling? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3374) Overlay sendRedirect to get relative Location header
[ https://issues.apache.org/jira/browse/SLING-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891929#comment-13891929 ] Felix Meschberger commented on SLING-3374: -- Technically we can (and in an internal discussion I may actually have stipulated that we) implement the sendRedirect method in Sling to return a relative path. There are two problems, though with respect to specification compliance: # The Servlet API spec requires the [sendRedirect|http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendRedirect%28java.lang.String%29] method to set an absolute URL on the Location header. # The current HTTP/1.1 spec (RFC 2616) mandates the [Location|http://tools.ietf.org/html/rfc2616#section-14.30] header to be an absolute URI (which is considered a bug to be fixed in the upcoming HTTP spec: http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.location). Given that the HTTP spec is being updated and most if not all modern browsers today support relative URI Location headers, it would be conceivable to wrap the sendRedirect method to always use a relative URL instead of forcing an absolute one. But then: what would be the benefit of having a relative URL as opposed to an absolute URL ? Could it be that the HttpServletRequest.getServerName and HttpServletRequest.getServerPort yield wrong (or unexpected) values behind a caching proxy ? Overlay sendRedirect to get relative Location header Key: SLING-3374 URL: https://issues.apache.org/jira/browse/SLING-3374 Project: Sling Issue Type: Bug Reporter: Laurie byrum Recently, Location headers returned from redirects started being absolute instead of relative. We should try to decorate this in sling. Can we replace the sendRedirect with a set-header set-status combination in sling? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891930#comment-13891930 ] Marius Petria commented on SLING-3352: -- [~fmeschbe], there are several proposals for exposing configuration as JCR nodes. I will try to summarize them here: 1. fully synchronize certain configs in a designated location 2. have shadow nodes for those configs, i.e. syncronize only the creation and deletion and resort to some other mechanisms for read and update 3. do not create another copy but enhance the current JCR installer to put the copies it already creates into a designated location for a certain factory Can you please share your thoughts on these? Are we going in the right direction? Please have in mind that while some solutions are proposed to be general the issue we are trying to solve is particular to replication. We want to securely access through HTTP active configurations of replication agents. Expose OSGI configuration as JCR nodes -- Key: SLING-3352 URL: https://issues.apache.org/jira/browse/SLING-3352 Project: Sling Issue Type: Improvement Reporter: Marius Petria Labels: replication We need a safe way to expose OSGI configuration via HTTP. Requirements: - all configs for a certain factory should be manageable - they should have associated JCR nodes that contain the config properties - only configs that are available through ConfigurationAdmin should be available - the HTTP urls should have friendly names - (Optional) the implementation should be general enough to be used for other configs other than replication if needed For example: a configuration with name publish for org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory should be mapped to /etc/replication/agent/publish Problems with current implementation of JCR nodes created by JCR installed: - Configuration files are read and created from /apps/.../config or /libs/.../config, and there is no easy way to determine which are active in the ConfigurationAdmin - There is no way to restrict a repository path to create only configuration from a specified factory (making it unusable with relaxed ACLs) - The url of a configuration is unfriendly (it contains the fully qualified name of the factory) - The node types are not homogenous making it hard to use in a client application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3374) Overlay sendRedirect to set relative Location header
[ https://issues.apache.org/jira/browse/SLING-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3374: --- Summary: Overlay sendRedirect to set relative Location header (was: Overlay sendRedirect to get relative Location header) Overlay sendRedirect to set relative Location header Key: SLING-3374 URL: https://issues.apache.org/jira/browse/SLING-3374 Project: Sling Issue Type: Bug Reporter: Laurie byrum Recently, Location headers returned from redirects started being absolute instead of relative. We should try to decorate this in sling. Can we replace the sendRedirect with a set-header set-status combination in sling? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3001) Support wildcard (was: regular expressions) in IP whitelist for discovery/topology connectors
[ https://issues.apache.org/jira/browse/SLING-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-3001: --- Affects Version/s: Discovery Impl 1.0.2 Support wildcard (was: regular expressions) in IP whitelist for discovery/topology connectors - Key: SLING-3001 URL: https://issues.apache.org/jira/browse/SLING-3001 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently the IP white listing feature of discovery.impl requires explicit IP addresses or fully qualified hostnames. I more complex setups it can be useful to define regular expressions, eg for hostnames, eg *.mydomain.com. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3374) Overlay sendRedirect to set relative Location header
[ https://issues.apache.org/jira/browse/SLING-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891937#comment-13891937 ] Bertrand Delacretaz commented on SLING-3374: There are valid cases for both relative and absolute Location URI in a response, as described in the draft-ietf-httpbis-p2-semantics-25 that you point to. What we might do is override sendRedirect to make sure it respects the intention (absolute or relative Location) of the caller, using set header + set status calls as suggested, instead of calling the sendRedirect of the response object that we wrap. Overlay sendRedirect to set relative Location header Key: SLING-3374 URL: https://issues.apache.org/jira/browse/SLING-3374 Project: Sling Issue Type: Bug Reporter: Laurie byrum Recently, Location headers returned from redirects started being absolute instead of relative. We should try to decorate this in sling. Can we replace the sendRedirect with a set-header set-status combination in sling? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (SLING-3368) Simplify JSONObject and JSONArray access
[ https://issues.apache.org/jira/browse/SLING-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890908#comment-13890908 ] Nicolas Peltier edited comment on SLING-3368 at 2/5/14 9:27 AM: proposed new patch - both JSONArray JSONObject implement Adaptable - kept Iterable implementation for JSONArray for different use cases - makes immutable the returned values - added some basic tests was (Author: npeltier): proposed path for adaptTo: - kept Iterable for JSONArray for different use cases - makes immutable the returned values - added some basic tests Simplify JSONObject and JSONArray access Key: SLING-3368 URL: https://issues.apache.org/jira/browse/SLING-3368 Project: Sling Issue Type: Improvement Components: Commons Reporter: Nicolas Peltier Priority: Minor Attachments: [json]_add_JSONArray_adaptTo(List_class),_JSONObject_adaptTo(Map_class),_iterable_JSONArra.patch, [json]_add_other_ways_to_use_JSONArray_and_JSONObject.patch Map JSONObject.toMap and JSONArray implementing Iterable allows better usage of those classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3375) HttpClient use in org.apache.sling.discovery.impl package does not close method connections explicitely
Timothee Maret created SLING-3375: - Summary: HttpClient use in org.apache.sling.discovery.impl package does not close method connections explicitely Key: SLING-3375 URL: https://issues.apache.org/jira/browse/SLING-3375 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Timothee Maret Using the sling topology in our application, we experience instances being disconnected from the topology. Looking at our logs, we see occurrences of IOExceptions and then the instance can't connect anymore. Looking at the use of HttpClient in the package 'org.apache.sling.discovery.impl' I noticed the method was not released explicitely although advised by the lib doc [0]. org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient#ping org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient#disconnect [0] https://hc.apache.org/httpclient-3.x/tutorial.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[discovery] including commons-net
Hi all, For implementing SLING-3001 I'd like to include apache's commons-net (3.3) as it contains a nice utility for doing CIDR and mask calculations (SubnetUtils). Any objects? Cheers, Stefan
Re: [discovery] including commons-net
Yes, I'm only using that one atm. So inlining sounds like a good idea! Cheers, Stefan On 2/5/14 12:26 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: If you are only going to use SubnetUtils [1] then we can possibly inline it in the bundle as it appears to be not depending on any other class in commons-net Chetan Mehrotra [1] https://github.com/apache/commons-net/blob/trunk/src/main/java/org/apache/ commons/net/util/SubnetUtils.java On Wed, Feb 5, 2014 at 4:44 PM, Stefan Egli e...@adobe.com wrote: Just checked. The exports look clean: only org.apache.commons.net.* The imports too: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl But the size is not tremendously small - it is 280kB.. - but within the range of the other apache's commons-* Cheers, Stefan On 2/5/14 11:53 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Stefan, On Wed, Feb 5, 2014 at 11:46 AM, Stefan Egli e...@adobe.com wrote: ...For implementing SLING-3001 I'd like to include apache's commons-net (3.3) as it contains a nice utility for doing CIDR and mask calculations (SubnetUtils) What does that mean, is that just a new small bundle with clean package exports/imports? If yes I'm ok with it. -Bertrand
[jira] [Assigned] (SLING-3372) Unable to deploy org.apache.sling.launchpad-7-SNAPSHOT.war on jetty-distribution-9.1.1.v20140108
[ https://issues.apache.org/jira/browse/SLING-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-3372: Assignee: Felix Meschberger Unable to deploy org.apache.sling.launchpad-7-SNAPSHOT.war on jetty-distribution-9.1.1.v20140108 Key: SLING-3372 URL: https://issues.apache.org/jira/browse/SLING-3372 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Builder 7 Environment: jetty-distribution-9.1.1.v20140108 Reporter: Rohit Kumar Assignee: Felix Meschberger Attachments: Sling-3372.patch While deploying org.apache.sling.launchpad-7-SNAPSHOT.war we get following exception 14-02-04 23:06:59.027:INFO:oasl.war:main: sling: Sling Extension Lib Home : /home/rohkuma/Documents/software/java/sling_jetty/lib/ext 2014-02-04 23:06:59.028:INFO:oasl.war:main: sling: No Launcher JAR to install 2014-02-04 23:06:59.029:INFO:oasl.war:main: sling: Loading launcher class org.apache.sling.launchpad.base.webapp.SlingServletDelegate from org.apache.sling.launchpad.base.jar 2014-02-04 23:06:59.029:WARN:oasl.war:main: sling: Cannot load Launcher Servlet org.apache.sling.launchpad.base.webapp.SlingServletDelegate java.lang.IllegalArgumentException: Sling Launcher JAR /home/rohkuma/Documents/software/java/sling_jetty/org.apache.sling.launchpad.base.jar is not accessible at org.apache.sling.launchpad.base.shared.Loader.loadLauncher(Loader.java:102) at org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:363) at org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:325) at org.apache.sling.launchpad.webapp.SlingServlet.init(SlingServlet.java:118) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:561) at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:351) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3372) Unable to deploy org.apache.sling.launchpad-7-SNAPSHOT.war on jetty-distribution-9.1.1.v20140108
[ https://issues.apache.org/jira/browse/SLING-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-3372: - Affects Version/s: (was: Launchpad Builder 7) Launchpad Base 2.5.0 Unable to deploy org.apache.sling.launchpad-7-SNAPSHOT.war on jetty-distribution-9.1.1.v20140108 Key: SLING-3372 URL: https://issues.apache.org/jira/browse/SLING-3372 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Base 2.5.0 Environment: jetty-distribution-9.1.1.v20140108 Reporter: Rohit Kumar Assignee: Felix Meschberger Fix For: Launchpad Base 2.5.2 Attachments: Sling-3372.patch While deploying org.apache.sling.launchpad-7-SNAPSHOT.war we get following exception 14-02-04 23:06:59.027:INFO:oasl.war:main: sling: Sling Extension Lib Home : /home/rohkuma/Documents/software/java/sling_jetty/lib/ext 2014-02-04 23:06:59.028:INFO:oasl.war:main: sling: No Launcher JAR to install 2014-02-04 23:06:59.029:INFO:oasl.war:main: sling: Loading launcher class org.apache.sling.launchpad.base.webapp.SlingServletDelegate from org.apache.sling.launchpad.base.jar 2014-02-04 23:06:59.029:WARN:oasl.war:main: sling: Cannot load Launcher Servlet org.apache.sling.launchpad.base.webapp.SlingServletDelegate java.lang.IllegalArgumentException: Sling Launcher JAR /home/rohkuma/Documents/software/java/sling_jetty/org.apache.sling.launchpad.base.jar is not accessible at org.apache.sling.launchpad.base.shared.Loader.loadLauncher(Loader.java:102) at org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:363) at org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:325) at org.apache.sling.launchpad.webapp.SlingServlet.init(SlingServlet.java:118) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:561) at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:351) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [discovery] including commons-net
On Wed, Feb 5, 2014 at 1:22 PM, Stefan Egli e...@adobe.com wrote: Yes, I'm only using that one atm. So inlining sounds like a good idea!... I agree, if it's just one class that might be easier. Otherwise from the details that you supplied I'd be ok with adding that bundle. -Bertrand
[jira] [Commented] (SLING-3369) framework-extension-ws fragment should include javax.xml.rpc
[ https://issues.apache.org/jira/browse/SLING-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892097#comment-13892097 ] Felix Meschberger commented on SLING-3369: -- While I was under the assumption that javax.xml.rpc was part of the Java platform, I have now quickly crosschecked and neither Java 7 nore Java 8 have this package in their runtime class library. So we should probably not add it to any of the fragments. framework-extension-ws fragment should include javax.xml.rpc Key: SLING-3369 URL: https://issues.apache.org/jira/browse/SLING-3369 Project: Sling Issue Type: Bug Components: Extensions Reporter: Justin Edelson Could also go in framework-extension-xml, but I think javax.xml.rpc is roughly a peer of javax.xml.soap, which is in framework-extension-ws. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3369) framework-extension-ws fragment should include javax.xml.rpc
[ https://issues.apache.org/jira/browse/SLING-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-3369. --- Resolution: Won't Fix I was under the same impression. Thanks for double checking. framework-extension-ws fragment should include javax.xml.rpc Key: SLING-3369 URL: https://issues.apache.org/jira/browse/SLING-3369 Project: Sling Issue Type: Bug Components: Extensions Reporter: Justin Edelson Could also go in framework-extension-xml, but I think javax.xml.rpc is roughly a peer of javax.xml.soap, which is in framework-extension-ws. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
buildbot failure in ASF Buildbot on sling-trunk
The Buildbot has detected a new failure on builder sling-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/sling-trunk/builds/244 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch sling/trunk] 1564784 Blamelist: stefanegli BUILD FAILED: failed compile sincerely, -The Buildbot
[jira] [Resolved] (SLING-3001) Support wildcard (was: regular expressions) in IP whitelist for discovery/topology connectors
[ https://issues.apache.org/jira/browse/SLING-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-3001. Resolution: Fixed added support for wildcards. so besides using a message signature (hmac) there are now 4 variants for configuring the whitelist: * plaintext hostname * plaintext IP address * wildcards (* and/or ?), either in hostname or IP address * IP-subnet, either in CIDR notation (1.2.3.4/24) or IP_space_subnet (1.2.3.4 255.255.255.0) Support wildcard (was: regular expressions) in IP whitelist for discovery/topology connectors - Key: SLING-3001 URL: https://issues.apache.org/jira/browse/SLING-3001 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently the IP white listing feature of discovery.impl requires explicit IP addresses or fully qualified hostnames. I more complex setups it can be useful to define regular expressions, eg for hostnames, eg *.mydomain.com. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [discovery] including commons-net
On 2/5/14 2:28 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Feb 5, 2014 at 1:22 PM, Stefan Egli e...@adobe.com wrote: Yes, I'm only using that one atm. So inlining sounds like a good idea!... I agree, if it's just one class that might be easier. I embedded that one class for now (in discovery.impl). If we need more classes of commons-net we can still require that entire bundle. Cheers, Stefan
buildbot success in ASF Buildbot on sling-trunk
The Buildbot has detected a restored build on builder sling-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/sling-trunk/builds/245 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch sling/trunk] 1564785 Blamelist: stefanegli Build succeeded! sincerely, -The Buildbot
[jira] [Created] (SLING-3376) TenantProvider passes tenant with old state to TenantCustomizer
Roland Schaer created SLING-3376: Summary: TenantProvider passes tenant with old state to TenantCustomizer Key: SLING-3376 URL: https://issues.apache.org/jira/browse/SLING-3376 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.0 Reporter: Roland Schaer Priority: Minor The TenantProvider does pass a Tenant with the old state to the TenantCustomizer#setup() method, making it impossible to handle changes on the update case. I would expect to have a Tenant (in a transient state) passed which reflects the new state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3367) gzip topology announcements
[ https://issues.apache.org/jira/browse/SLING-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892272#comment-13892272 ] Stefan Egli commented on SLING-3367: One issue here is backwards compatibility: if a new gzip-ping discovery.impl client connects to an old discovery.impl servlet which doesn't understand gzip, it would likely reject the connector. gzip topology announcements --- Key: SLING-3367 URL: https://issues.apache.org/jira/browse/SLING-3367 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently topology announcements are sent as plain-text JSON. If used in a large setup, the announcements grow in size and it would make a lot of sense to gzip it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3367) gzip topology announcements
[ https://issues.apache.org/jira/browse/SLING-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892332#comment-13892332 ] Timothee Maret commented on SLING-3367: --- [~egli], I think we should follow the HTTP spec and leverage the Accept-Encoding header. Only the response would optionally (if requested) be gzipped. IMO for the discovery case it will cover most of the data transferred (means good enough) as for each ping the data sent represent one single instance data while the data received represent n instances. gzip topology announcements --- Key: SLING-3367 URL: https://issues.apache.org/jira/browse/SLING-3367 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently topology announcements are sent as plain-text JSON. If used in a large setup, the announcements grow in size and it would make a lot of sense to gzip it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3376) TenantProvider passes tenant with old state to TenantCustomizer
[ https://issues.apache.org/jira/browse/SLING-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Schaer updated SLING-3376: - Attachment: SLING-3376.patch adding possible patch TenantProvider passes tenant with old state to TenantCustomizer --- Key: SLING-3376 URL: https://issues.apache.org/jira/browse/SLING-3376 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.0 Reporter: Roland Schaer Priority: Minor Attachments: SLING-3376.patch The TenantProvider does pass a Tenant with the old state to the TenantCustomizer#setup() method, making it impossible to handle changes on the update case. I would expect to have a Tenant (in a transient state) passed which reflects the new state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
sling pull request: SLING-3376 - TenantProvider passes tenant with old stat...
GitHub user roele opened a pull request: https://github.com/apache/sling/pull/11 SLING-3376 - TenantProvider passes tenant with old state to TenantCustomizer You can merge this pull request into a Git repository by running: $ git pull https://github.com/roele/sling trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/11.patch commit 953e29eb2d228cbe1232784fe91e58835be4cd21 Author: Roland Schaer rsch...@adobe.com Date: 2014-02-05T17:45:41Z SLING-3376 - TenantProvider passes tenant with old state to TenantCustomizer
[jira] [Comment Edited] (SLING-3367) gzip topology announcements
[ https://issues.apache.org/jira/browse/SLING-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892332#comment-13892332 ] Timothee Maret edited comment on SLING-3367 at 2/5/14 6:28 PM: --- [~egli], I think we should follow the HTTP spec and leverage the Accept-Encoding header. Only the response would optionally (if requested) be gzipped. IMO for the discovery case it will cover most of the data transferred (means good enough) as for each ping the data sent represent one single instance data while the data received represent n instances. Request gzip could also be enabled via a osgi configuration (disabled by default). was (Author: marett): [~egli], I think we should follow the HTTP spec and leverage the Accept-Encoding header. Only the response would optionally (if requested) be gzipped. IMO for the discovery case it will cover most of the data transferred (means good enough) as for each ping the data sent represent one single instance data while the data received represent n instances. gzip topology announcements --- Key: SLING-3367 URL: https://issues.apache.org/jira/browse/SLING-3367 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Currently topology announcements are sent as plain-text JSON. If used in a large setup, the announcements grow in size and it would make a lot of sense to gzip it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (SLING-3376) TenantProvider passes tenant with old state to TenantCustomizer
[ https://issues.apache.org/jira/browse/SLING-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Gupta reassigned SLING-3376: - Assignee: Amit Gupta TenantProvider passes tenant with old state to TenantCustomizer --- Key: SLING-3376 URL: https://issues.apache.org/jira/browse/SLING-3376 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.0 Reporter: Roland Schaer Assignee: Amit Gupta Priority: Minor Attachments: SLING-3376.patch The TenantProvider does pass a Tenant with the old state to the TenantCustomizer#setup() method, making it impossible to handle changes on the update case. I would expect to have a Tenant (in a transient state) passed which reflects the new state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3376) TenantProvider passes tenant with old state to TenantCustomizer
[ https://issues.apache.org/jira/browse/SLING-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893063#comment-13893063 ] Amit Gupta commented on SLING-3376: --- Thanks for the patch applied At revision: 1565082 TenantProvider passes tenant with old state to TenantCustomizer --- Key: SLING-3376 URL: https://issues.apache.org/jira/browse/SLING-3376 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.0 Reporter: Roland Schaer Assignee: Amit Gupta Priority: Minor Attachments: SLING-3376.patch The TenantProvider does pass a Tenant with the old state to the TenantCustomizer#setup() method, making it impossible to handle changes on the update case. I would expect to have a Tenant (in a transient state) passed which reflects the new state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3359) Classloader Leak Detector Console Tab
[ https://issues.apache.org/jira/browse/SLING-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893097#comment-13893097 ] Chetan Mehrotra commented on SLING-3359: Also opened enhancement bug FELIX-4418 to enable some support from framework in identifying such leaky classloaders while doing heap dump analysis Classloader Leak Detector Console Tab - Key: SLING-3359 URL: https://issues.apache.org/jira/browse/SLING-3359 Project: Sling Issue Type: New Feature Components: Console Reporter: Ian Boston Assignee: Chetan Mehrotra Attachments: org.apache.sling.extensions.classloader-leak-detector-0.0.1-SNAPSHOT-src.zip Chetan has created a classloader leak detector console at https://github.com/chetanmeh/sling-leak-detector. It would be really good to get this into the contrib are and released so that consumers of Sling can use it to locate code in bundles that is leaking classloaders. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3340) Warnings on startup regarding no-op loggers
[
https://issues.apache.org/jira/browse/SLING-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893099#comment-13893099
]
Chetan Mehrotra commented on SLING-3340:
The bug has been fixed in Slf4j and a new release 1.7.6 with the fix is
available [1]
[1] http://www.slf4j.org/news.html
Warnings on startup regarding no-op loggers
---
Key: SLING-3340
URL: https://issues.apache.org/jira/browse/SLING-3340
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Depening on the order in which bundles are installed Slf4j might use NoOp
loggers for loggers created before Logback is initialized. One would see a
warning log like below
{noformat}
Slf4j is not initialized yet. Delaying Logback support initialization
SLF4J: The following loggers will not work because they were created
SLF4J: during the default configuration phase of the underlying logging
system.
SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
SLF4J: org.apache.sling.commons.logservice
SLF4J: org.apache.sling.installer.core
SLF4J: org.apache.sling.installer.core.impl.OsgiInstallerImpl
SLF4J: org.apache.sling.audit.osgi.installer
SLF4J: org.apache.sling.installer.core.impl.PersistentResourceList
SLF4J: org.apache.sling.installer.core.impl.EntityResourceList
SLF4J: org.apache.sling.installer.core.impl.tasks.BundleTaskCreator
SLF4J: org.apache.sling.installer.core.impl.DefaultTransformer
SLF4J: org.apache.sling.installer.provider.file
SLF4J: org.apache.sling.installer.provider.file.impl.ServicesListener
SLF4J: org.apache.sling.installer.provider.file.impl.FileInstaller
SLF4J: org.apache.sling.javax.activation
SLF4J: org.apache.sling.javax.activation.internal.Activator
SLF4J: org.apache.sling.javax.activation.internal.OsgiMailcapCommandMap
SLF4J: org.apache.sling.launchpad.installer
SLF4J: org.apache.sling.settings
SLF4J: org.apache.sling.settings.impl.SlingSettingsServiceImpl
SLF4J: org.apache.sling.launchpad.installer.impl.LaunchpadConfigInstaller
SLF4J: org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask
{noformat}
Given that log from Sling installer category are important and should not be
lost we should avoid such scenario to be created.
See thread http://markmail.org/thread/n4zyj5akkh24ahh5
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [logging] warnings on startup regarding no-op loggers
Just an update. The issue has now been fixed on Slf4j side and a new release 1.7.6 was made which contains the fix. So this completes the #3 approach mentioned previously. With this there is just a small issue that while Slf4j is getting initialized the log message would get lost as at that time NOP Loggers are used. Once initialization is complete the log message from such loggers would be handled in default way. To fix this we would need to control the startup order and get the Commons Log bundle started first. Chetan Mehrotra On Wed, Jan 29, 2014 at 4:47 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Carsten Ziegeler cziege...@apache.org wrote: never ever rely on that. Agreed. But ... And for B we would need changes at least in the launchpad - for A we just fix slf4j Change in our code is in our control and easy to do without incurring any penalty. Fix in Slf4j might take time. So its like a workaround untill proper fix is done. Chetan Mehrotra
[jira] [Commented] (SLING-2529) Add support for JCR Observation event types: NODE_MOVED and PERSIST
[ https://issues.apache.org/jira/browse/SLING-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893135#comment-13893135 ] Mario Rodriguez Jaen commented on SLING-2529: - Besides adding those two event types to the listener, is there something else to be done at the 'handler' side? I understand that the events should be send to the *EventAdmin* once they are set with their proper resourceType and superResType. Add support for JCR Observation event types: NODE_MOVED and PERSIST --- Key: SLING-2529 URL: https://issues.apache.org/jira/browse/SLING-2529 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.1.0 Reporter: Felix Meschberger Assignee: Felix Meschberger The JcrResourceListener does not currently support two event types added in the JCR 2.0 specification: * NODE_MOVED * PERSIST Particularly NODE_MOVED is an important event which we should support with a properly mapped OSGi event. The PERSIST event might be useful in creating event group boundaries. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
