[jira] [Updated] (SLING-5827) HeltthCheckMetadata ClassCast Exception
[
https://issues.apache.org/jira/browse/SLING-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivo Leitão updated SLING-5827:
--
Description:
I'm getting a classcastexception in the healthcheck component. This is
happenning only for my components (don't know why :-S).
I have looked at the source code and in my case at the AsyncHelthCheckExecutor
the code passes the lines bellow
{code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
ServiceReference serviceReference = event.getServiceReference();
final boolean isHealthCheck =
serviceReference.isAssignableTo(bundleContext.getBundle(),
HealthCheck.class.getName());
if (isHealthCheck) {
// True at my case
}
{code}
Later in the method getHealthCheckTitle of the class HealthCheckMetadata at the
line bellow:
{code:title=HealthCheckMetadata.java|borderStyle=solid}
if (StringUtils.isBlank(name)) {
name = (String) ref.getProperty(Constants.SERVICE_PID);
}
{code}
ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have the
stacktrace bellow as a result
{code:title=Stacktrace|borderStyle=solid}
java.lang.ClassCastException: java.util.ArrayList cannot be cast to
java.lang.String
at
org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
at
org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
at
org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at aQute.launcher.Launcher.update(Launcher.java:482)
at aQute.launcher.Launcher.activate(Launcher.java:381)
at aQute.launcher.Launcher.run(Launcher.java:275)
at aQute.launcher.Launcher.main(Launcher.java:132)
{code}
was:
I'm getting a classcastexception in the healthcheck component. This is
happenning only for my components (don't know why :-S).
I have looked at the source code and in my case at the AsyncHelthCheckExecutor
the code pass
[jira] [Updated] (SLING-5827) HeltthCheckMetadata ClassCast Exception
[
https://issues.apache.org/jira/browse/SLING-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivo Leitão updated SLING-5827:
--
Description:
I'm getting a classcastexception in the healthcheck component. This is
happenning only for my components (don't know why :-S).
I have looked at the source code and in my case at the AsyncHelthCheckExecutor
the code passes the lines bellow
{code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
ServiceReference serviceReference = event.getServiceReference();
final boolean isHealthCheck =
serviceReference.isAssignableTo(bundleContext.getBundle(),
HealthCheck.class.getName());
if (isHealthCheck) {
// True at my case
}
{code}
Later in the method getHealthCheckTitle of the class HealthCheckMetadata at the
line bellow:
if (StringUtils.isBlank(name)) {
name = (String) ref.getProperty(Constants.SERVICE_PID);
}
ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have the
stacktrace bellow as a result
java.lang.ClassCastException: java.util.ArrayList cannot be cast to
java.lang.String
at
org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
at
org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
at
org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at aQute.launcher.Launcher.update(Launcher.java:482)
at aQute.launcher.Launcher.activate(Launcher.java:381)
at aQute.launcher.Launcher.run(Launcher.java:275)
at aQute.launcher.Launcher.main(Launcher.java:132)
was:
I'm getting a classcastexception in the healthcheck component. This is
happenning only for my components (don't know why :-S).
I have looked at the source code and in my case at the AsyncHelthCheckExecutor
the code passes the lines bellow
ServiceReference serviceReference = event.getServiceReference();
final boolean isHe
[jira] [Created] (SLING-5827) HeltthCheckMetadata ClassCast Exception
Ivo Leitão created SLING-5827:
-
Summary: HeltthCheckMetadata ClassCast Exception
Key: SLING-5827
URL: https://issues.apache.org/jira/browse/SLING-5827
Project: Sling
Issue Type: Bug
Components: Health Check
Affects Versions: Health Check Core 1.2.4
Reporter: Ivo Leitão
Priority: Critical
I'm getting a classcastexception in the healthcheck component. This is
happenning only for my components (don't know why :-S).
I have looked at the source code and in my case at the AsyncHelthCheckExecutor
the code passes the lines bellow
ServiceReference serviceReference = event.getServiceReference();
final boolean isHealthCheck =
serviceReference.isAssignableTo(bundleContext.getBundle(),
HealthCheck.class.getName());
if (isHealthCheck) {
// True at my case
}
Later in the method getHealthCheckTitle of the class HealthCheckMetadata at the
line bellow:
if (StringUtils.isBlank(name)) {
name = (String) ref.getProperty(Constants.SERVICE_PID);
}
ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have the
stacktrace bellow as a result
java.lang.ClassCastException: java.util.ArrayList cannot be cast to
java.lang.String
at
org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
at
org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
at
org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at aQute.launcher.Launcher.update(Launcher.java:482)
at aQute.launcher.Launcher.activate(Launcher.java:381)
at aQute.launcher.Launcher.run(Launcher.java:275)
at aQute.launcher.Launcher.main(Launcher.java:132)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5753) Use.init() not invoked for Java Use object which is also a Sling Model
[ https://issues.apache.org/jira/browse/SLING-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-5753. - Resolution: Won't Fix Assignee: Radu Cotescu > Use.init() not invoked for Java Use object which is also a Sling Model > -- > > Key: SLING-5753 > URL: https://issues.apache.org/jira/browse/SLING-5753 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Models Use Provider 1.0.0 >Reporter: Levente Santha >Assignee: Radu Cotescu >Priority: Minor > Attachments: SLING_5753.patch > > > [~kwin], > In the situation where I start with a Java Use object and later decide to use > some convenient features of Sling Models, I have the surprise to experience > that as soon as my Java Use object gets the @Model annotation its init() > method is not invoked any more. > I can see no good reason for this, so I created a patch to fix it. > Please let me know what you think. > Thank you, Levente -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5753) Use.init() not invoked for Java Use object which is also a Sling Model
[
https://issues.apache.org/jira/browse/SLING-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366344#comment-15366344
]
Radu Cotescu commented on SLING-5753:
-
I have to agree with Justin's comment \[0\]: implementing this enhancement will
lead to inconsistency regarding Sling Models instantiation depending on the
consumer. Since anything that can be performed in
{{Use#init(javax.script.Bindings)}} can be accomplished through injection
annotations and / or {{@PostConstruct}} I don't see a compelling reason for
applying the attached patch.
\[0\] -
https://issues.apache.org/jira/browse/SLING-5753?focusedCommentId=15308307&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15308307
> Use.init() not invoked for Java Use object which is also a Sling Model
> --
>
> Key: SLING-5753
> URL: https://issues.apache.org/jira/browse/SLING-5753
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Models Use Provider 1.0.0
>Reporter: Levente Santha
>Priority: Minor
> Attachments: SLING_5753.patch
>
>
> [~kwin],
> In the situation where I start with a Java Use object and later decide to use
> some convenient features of Sling Models, I have the surprise to experience
> that as soon as my Java Use object gets the @Model annotation its init()
> method is not invoked any more.
> I can see no good reason for this, so I created a patch to fix it.
> Please let me know what you think.
> Thank you, Levente
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5632) [Sightly] URI manipulation options that process a path should not alter URIs that don't provide path information
[
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366180#comment-15366180
]
Radu Cotescu commented on SLING-5632:
-
[~fvisser], I've changed the issue's summary in order to better reflect the
problem. I've realised that not only the {{extension}} option could have caused
problems, but rather all options processing the URI's path or path-dependent
elements like selectors and fragments.
> [Sightly] URI manipulation options that process a path should not alter URIs
> that don't provide path information
>
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Labels: Sightly
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't
> contain any path information "http://www.google.com";, then we don't want to
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-5632) [sightly] Support for external links with @ extension
[
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-5632:
---
Assignee: Radu Cotescu
> [sightly] Support for external links with @ extension
> -
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Labels: Sightly
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't
> contain any path information "http://www.google.com";, then we don't want to
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5632) [Sightly] URI manipulation options that process a path should not alter URIs that don't provide path information
[
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5632:
Summary: [Sightly] URI manipulation options that process a path should not
alter URIs that don't provide path information (was: [sightly] Support for
external links with @ extension)
> [Sightly] URI manipulation options that process a path should not alter URIs
> that don't provide path information
>
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Labels: Sightly
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't
> contain any path information "http://www.google.com";, then we don't want to
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5632) [sightly] Support for external links with @ extension
[
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5632:
Fix Version/s: Scripting Sightly Engine 1.0.20
> [sightly] Support for external links with @ extension
> -
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Labels: Sightly
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't
> contain any path information "http://www.google.com";, then we don't want to
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5632) [sightly] Support for external links with @ extension
[
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5632:
Description:
Code example
{noformat}
Our link
{noformat}
This normally works ok, but in case {{path}} points to a URL that doesn't
contain any path information "http://www.google.com";, then we don't want to add
the extension.
Now this check has to be done every time we use the {{extension}} option.
was:
Code example
Our link
This normally this goes ok, but in case path points to an external like
"http://www.google.com";, then we don't want to add the extension.
Now this check has to be done everytime we use @ extension
> [sightly] Support for external links with @ extension
> -
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Feike Visser
> Labels: Sightly
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't
> contain any path information "http://www.google.com";, then we don't want to
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366120#comment-15366120
]
Bertrand Delacretaz commented on SLING-5824:
bq. This to me seem like a great bypass for out CSRF protection
Another good reason not to do this then!
[~christanto] at this point I think making your alias scripts cleaner is a much
better solution, you might for example add a "forwarder" object in the
scripting context via a Sling {{BindingsValuesProvider}}, with fluent methods
like {{forwarder.for(request.response).aliasToGetMethod()}} to make things
clean and explicit.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5692) Add Integration Tests for Scripting FreeMarker
[
https://issues.apache.org/jira/browse/SLING-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366129#comment-15366129
]
Oliver Lietz commented on SLING-5692:
-
module {{org.apache.sling.scripting.freemarker.it}} merged into
{{org.apache.sling.scripting.freemarker}} in
[r1751792|https://svn.apache.org/r1751792]
> Add Integration Tests for Scripting FreeMarker
> --
>
> Key: SLING-5692
> URL: https://issues.apache.org/jira/browse/SLING-5692
> Project: Sling
> Issue Type: Task
> Components: Scripting, Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting FreeMarker 1.0.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366125#comment-15366125
]
Christanto commented on SLING-5824:
---
But this is just another GET request. I don't understand.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366111#comment-15366111
]
Carsten Ziegeler commented on SLING-5824:
-
I was wondering about the same as Antonio - as you say that you usually use GET
and only if the url gets too long switch to POST, so for the GETs you're
bypassing the protection
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366105#comment-15366105
]
Christanto commented on SLING-5824:
---
This is about converting POST to GET, not the other way around.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5692) Add Integration Tests for Scripting FreeMarker
[ https://issues.apache.org/jira/browse/SLING-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-5692: Fix Version/s: (was: Scripting FreeMarker 1.0.2) Scripting FreeMarker 1.0.0 > Add Integration Tests for Scripting FreeMarker > -- > > Key: SLING-5692 > URL: https://issues.apache.org/jira/browse/SLING-5692 > Project: Sling > Issue Type: Task > Components: Scripting, Testing >Reporter: Oliver Lietz >Assignee: Oliver Lietz > Fix For: Scripting FreeMarker 1.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366094#comment-15366094
]
Antonio Sanso commented on SLING-5824:
--
just my 0.02 $ . We really need to be careful here. This to me seem like a
great bypass for out CSRF protection. As you might remember we do not check GET
requests in the CSRF protection...
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366061#comment-15366061
]
Christanto commented on SLING-5824:
---
Yes the script is trivial. The code at issue description is pretty much it.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366015#comment-15366015
]
Bertrand Delacretaz commented on SLING-5824:
bq. Both POST.jsp above have identical code, which is just to forward to GET.
I agree that's not fantastic but those scripts are probably trivial, right?
If not we might either provide utilities that make them trivial, or invent a
.forward or .redirect scripting engine for that, to avoid the filter tax that
Carsten mentions.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366010#comment-15366010
]
Carsten Ziegeler commented on SLING-5824:
-
With a generic filter you punish every request by executing that code - no
matter how small it is. I would assume you only have a few components where
this can happen, so I think that's fine if you have a simple post jsp for every
such component
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365997#comment-15365997
]
Christanto commented on SLING-5824:
---
bq. IIUC this happens in client code, so what prevents you from handling both
GET and POST in your server-side code?
It is not a blocker. The POST handler is currently written (as per the code
mentioned in the issue description) for each sling component that potentially
requires a POST like this.
You will notice the POST.jsp will be identical for each component. So this is a
good sign to solve it using filter, instead of servlet.
For example given the sling components in the system:
{code}
+ /libs/my/component1
+ component1.jsp
+ POST.jsp
+ /libs/my/component2
+ component2.jsp
+ POST.jsp
{code}
Both POST.jsp above have identical code, which is just to forward to GET.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365991#comment-15365991
]
Bertrand Delacretaz commented on SLING-5824:
bq. If the URL is not long we are using GET. If it is very long we can convert
to POST.
IIUC this happens in client code, so what prevents you from handling both GET
and POST in your server-side code?
If that's done at the servlet level for example, that's much more transparent
than a servlet filter manipulating request method names, which adds to the
Mystery Of What Happens Before My Servlet Runs.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365968#comment-15365968
]
Christanto commented on SLING-5824:
---
bq. But once you start using POST from client, as you mentioned in description,
this advantage is already lost. Isn't it
If the URL is not long we are using GET. If it is very long we can convert to
POST. There is no point to bookmark a very long URL, as some browsers don't
support that.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5824) Servlet Filter to do POST tunnelling to GET
[
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365947#comment-15365947
]
Amit Gupta commented on SLING-5824:
---
>GET is still preferable for the use case, as it allows bookmarking
But once you start using POST from client, as you mentioned in description,
this advantage is already lost. Isn't it
However the Security issues can be mitigated as mentioned by Roy in
https://issues.apache.org/jira/browse/SLING-53?focusedCommentId=12553455&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12553455
By only allowing POST to be changed to GET, not the other way.
Though, I am not still convinced about current use case, for this to be added
to Sling.
However, Couple of other reasons why it is needed are described in
http://fandry.blogspot.in/2012/03/x-http-header-method-override-and-rest.html
http://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers
Not sure, if Sling users need those.
> Servlet Filter to do POST tunnelling to GET
> ---
>
> Key: SLING-5824
> URL: https://issues.apache.org/jira/browse/SLING-5824
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example,
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the
> client do a POST request and then the server convert it to GET, so that the
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new
> HttpServletRequestWrapper(request) {
> @Override
> public String getMethod() {
> return "GET";
> }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time
> for this, it makes sense to implement this in Sling using Servlet Filter. For
> example, a special parameter can be introduced for this purpose named
> "\_method\_". So the filter will check for this parameter and wrap the
> request accordingly (also remove the "\_method\_"). This is similar to
> "\_charset\_" parameter for encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Javadoc and Java 8
On Thu, Jul 7, 2016 at 9:41 AM, Carsten Ziegeler wrote: > ...Fixing the javadoc for java 8 is not the nicest task in the world, but > you can usually do this fairly quickly I agree with that - the problem is that this pollutes diffs when comparing the code of a previous version of a module with a new release, which I often do. But that's life I guess... I'm ok for aiming to fix the javadocs, while being able to do releases with java 7 in the meantime. -Bertrand
[jira] [Comment Edited] (SLING-5682) special json array import for sling post servlet to post orderered structures
[
https://issues.apache.org/jira/browse/SLING-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365842#comment-15365842
]
Nicolas Peltier edited comment on SLING-5682 at 7/7/16 9:02 AM:
thx [~bdelacretaz]! i will need to submit a doc change as well
was (Author: npeltier):
thx [~bdelacretaz]!
> special json array import for sling post servlet to post orderered structures
> -
>
> Key: SLING-5682
> URL: https://issues.apache.org/jira/browse/SLING-5682
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Nicolas Peltier
>Assignee: Bertrand Delacretaz
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: SLING-5682-before.patch, SLING-5682.patch
>
>
> it is not possible right now to post an ordered structure through json data
> [0]. this ticket is for implementing [~bdelacretaz] proposal to use JSON
> Arrays:
> {noformat}
> {
>"title": "The parent node",
>"SLING:ordered": [{
>"SLING:name": "first",
>"title": "This comes first"
>}, {
>"SLING:name": "second",
>"title": "This comes second"
>}]
> }
> {noformat}
> This needs to be triggered by selector or content-type switch so that
> the existing POST behavior is unchanged.
> I suppose having SLING:ordered should then also set the appropriate
> mixin on the parent node.
> [0] http://sling.markmail.org/thread/plov2u7kibscn7sx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5682) special json array import for sling post servlet to post orderered structures
[
https://issues.apache.org/jira/browse/SLING-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365842#comment-15365842
]
Nicolas Peltier commented on SLING-5682:
thx [~bdelacretaz]!
> special json array import for sling post servlet to post orderered structures
> -
>
> Key: SLING-5682
> URL: https://issues.apache.org/jira/browse/SLING-5682
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Nicolas Peltier
>Assignee: Bertrand Delacretaz
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: SLING-5682-before.patch, SLING-5682.patch
>
>
> it is not possible right now to post an ordered structure through json data
> [0]. this ticket is for implementing [~bdelacretaz] proposal to use JSON
> Arrays:
> {noformat}
> {
>"title": "The parent node",
>"SLING:ordered": [{
>"SLING:name": "first",
>"title": "This comes first"
>}, {
>"SLING:name": "second",
>"title": "This comes second"
>}]
> }
> {noformat}
> This needs to be triggered by selector or content-type switch so that
> the existing POST behavior is unchanged.
> I suppose having SLING:ordered should then also set the appropriate
> mixin on the parent node.
> [0] http://sling.markmail.org/thread/plov2u7kibscn7sx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5826) add a change layer for sling pipes that modify content
[ https://issues.apache.org/jira/browse/SLING-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-5826: --- Description: would be nice to have a layer like operations & modification for post servlet for pipes, which would allow: - logging of operations done in the response (now we just have resulting resources or representations of them, and logs), - better dry run support - basis for adding backup functionnality was: would be nice to have a layer like operations & modification for post servlet for pipes, which would allow: - logging of operations done in the response (now we just have resulting resources or representations of them, and logs), - basis for adding backup functionnality > add a change layer for sling pipes that modify content > -- > > Key: SLING-5826 > URL: https://issues.apache.org/jira/browse/SLING-5826 > Project: Sling > Issue Type: Improvement >Reporter: Nicolas Peltier > > would be nice to have a layer like operations & modification for post servlet > for pipes, which would allow: > - logging of operations done in the response (now we just have resulting > resources or representations of them, and logs), > - better dry run support > - basis for adding backup functionnality -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5826) add a change layer for sling pipes that modify content
Nicolas Peltier created SLING-5826: -- Summary: add a change layer for sling pipes that modify content Key: SLING-5826 URL: https://issues.apache.org/jira/browse/SLING-5826 Project: Sling Issue Type: Improvement Reporter: Nicolas Peltier would be nice to have a layer like operations & modification for post servlet for pipes, which would allow: - logging of operations done in the response (now we just have resulting resources or representations of them, and logs), - basis for adding backup functionnality -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Javadoc and Java 8
Carsten Ziegeler wrote > Oliver Lietz wrote >> hi all, >> >> Javadoc became much stricter with doclint in Java 8 and releasing some >> (most?) >> of our modules with Java 8 will fail with Javadoc errors. >> >> Should Javadoc errors block a release? >> >> Should we enable Javadoc for regular builds? >> >> We can disable doclint for builds with Java 8 or fix the errors (+1) of >> course >> to get around. >> > > I think javadoc errors should block the release and we should fix them. > A release is still possible if you simply use java 7, so a simple > workaround exists. > > I guess it would make sense to enable javadoc building on our CI server, > however as we're not paying that much attention to what is happening > there anyway, I'm not sure if it helps. > > Fixing the javadoc for java 8 is not the nicest task in the world, but > you can usually do this fairly quickly. > And this is also a good opportunity to see whether the javadoc generation for a module works as expected or not. As I just found out while fixing the javadocs for the eventing module: the package excludes where not handled correctly at all. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Javadoc and Java 8
Oliver Lietz wrote > hi all, > > Javadoc became much stricter with doclint in Java 8 and releasing some > (most?) > of our modules with Java 8 will fail with Javadoc errors. > > Should Javadoc errors block a release? > > Should we enable Javadoc for regular builds? > > We can disable doclint for builds with Java 8 or fix the errors (+1) of > course > to get around. > I think javadoc errors should block the release and we should fix them. A release is still possible if you simply use java 7, so a simple workaround exists. I guess it would make sense to enable javadoc building on our CI server, however as we're not paying that much attention to what is happening there anyway, I'm not sure if it helps. Fixing the javadoc for java 8 is not the nicest task in the world, but you can usually do this fairly quickly. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
