Re: [VOTE] Release Apache Sling Testing Sling Mock 2.2.18, Servlet Helpers 1.1.4
+1 Stefan Seifert wrote > Hi, > > Apache Sling Testing Sling Mock 2.2.18 (1 issue) > https://issues.apache.org/jira/browse/SLING/fixforversion/12342676 > > Apache Sling Servlet Helpers 1.1.4 (1 issue) > https://issues.apache.org/jira/browse/SLING/fixforversion/12341766 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1877/ > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 1877 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > stefan > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling IDE Tooling version 1.2.2
+1 Robert Munteanu wrote > Hi, > > We solved 4 issues in this release: > https://issues.apache.org/jira/browse/SLING/fixforversion/12342559 > > The release candidate has been uploaded at > https://dist.apache.org/repos/dist/dev/sling, The release artifact is > the source bundle - org.apache.sling.ide.source-bundle-1.2.2.zip - > which can be used to build the project using > > mvn clean package > > The resulting binaries can be installed into an Eclipse instance from > the update site which is found at p2update/target/repository after > building the project. > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-ide-tooling.git;a=blob_plai > n;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 1.2.2 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling IDE Tooling version 1.2.2
On Mon, 2018-02-26 at 23:11 +0200, Robert Munteanu wrote: > Please vote to approve this release: +1 Checked signatures, ran smoke tests, verified IDE installation. Robert signature.asc Description: This is a digitally signed message part
[jira] [Comment Edited] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377598#comment-16377598
]
Justin Edelson edited comment on SLING-7508 at 2/26/18 9:26 PM:
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated. PR has been merged and a new IT has been added.
Thanks!
was (Author: justinedelson):
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated.
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7508.
---
Resolution: Fixed
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377597#comment-16377597
]
ASF GitHub Bot commented on SLING-7508:
---
justinedelson closed pull request #4: SLING-7508: fixed endless recursion
getModelClassForResource()
URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/4
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
b/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
index 3ee2fa5..8bac535 100644
--- a/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
+++ b/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
@@ -319,7 +319,11 @@ public void removeResourceTypeBindings(final Bundle
bundle) {
}
}
Resource resourceTypeResource =
resolver.getResource(originalResourceType);
-return getModelClassForResource(resourceTypeResource, map);
+if (resourceTypeResource != null &&
!resourceTypeResource.getPath().equals(resource.getPath())) {
+return getModelClassForResource(resourceTypeResource, map);
+} else {
+return null;
+}
}
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377598#comment-16377598
]
Justin Edelson commented on SLING-7508:
---
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated.
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] justinedelson closed pull request #4: SLING-7508: fixed endless recursion getModelClassForResource()
justinedelson closed pull request #4: SLING-7508: fixed endless recursion
getModelClassForResource()
URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/4
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
b/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
index 3ee2fa5..8bac535 100644
--- a/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
+++ b/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java
@@ -319,7 +319,11 @@ public void removeResourceTypeBindings(final Bundle
bundle) {
}
}
Resource resourceTypeResource =
resolver.getResource(originalResourceType);
-return getModelClassForResource(resourceTypeResource, map);
+if (resourceTypeResource != null &&
!resourceTypeResource.getPath().equals(resource.getPath())) {
+return getModelClassForResource(resourceTypeResource, map);
+} else {
+return null;
+}
}
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7508:
--
Fix Version/s: Sling Models Impl 1.4.8
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7508:
-
Assignee: Justin Edelson
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[VOTE] Release Apache Sling IDE Tooling version 1.2.2
Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12342559 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, The release artifact is the source bundle - org.apache.sling.ide.source-bundle-1.2.2.zip - which can be used to build the project using mvn clean package The resulting binaries can be installed into an Eclipse instance from the update site which is found at p2update/target/repository after building the project. You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-ide-tooling.git;a=blob_plai n;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 1.2.2 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours
[jira] [Updated] (SLING-7518) Deploying a new Sling bundle project from the create bundle wizard fails: Add and remove cannot both be null/empty
[
https://issues.apache.org/jira/browse/SLING-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-7518:
---
Issue Type: Bug (was: Task)
> Deploying a new Sling bundle project from the create bundle wizard fails: Add
> and remove cannot both be null/empty
> --
>
> Key: SLING-7518
> URL: https://issues.apache.org/jira/browse/SLING-7518
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.2
>
>
> {noformat}java.lang.IllegalArgumentException: Add and remove cannot both be
> null/empty
> at
> org.eclipse.wst.server.core.internal.Server.canModifyModules(Server.java:2489)
> at
> org.eclipse.wst.server.core.internal.ServerWorkingCopy.modifyModules(ServerWorkingCopy.java:546)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.deployProjectsOnServer(AbstractNewSlingApplicationWizard.java:190)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard$3.execute(AbstractNewSlingApplicationWizard.java:134)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:107)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2214)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:128)
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:437)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:353)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:980)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.performFinish(AbstractNewSlingApplicationWizard.java:130)
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:778)
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:417)
> at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619)
> at
> org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
> at org.eclipse.jface.window.Window.open(Window.java:794)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:115)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
> at
> org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
> at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:681)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:595)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at
> org.eclipse.core.runtime.int
[jira] [Updated] (SLING-3014) [build] Generate SCR descriptors using Maven
[ https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3014: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [build] Generate SCR descriptors using Maven > > > Key: SLING-3014 > URL: https://issues.apache.org/jira/browse/SLING-3014 > Project: Sling > Issue Type: Task > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > Attachments: SLING-3014-1.patch > > > _Edit_: updated the issue title to reflect the fact that we're looking to use > Maven, not a specific plug-in. > Since we're starting to use SCR descriptors when building the Sling IDE tools > it would be nice to generate them using the maven-scr-plugin. I have the > build working in the CLI, but not yet in the IDE ( see > http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is > done I'll commit my changes to trunk. > Note that plain Maven projects work just fine, this is about Tycho-driven > builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3963) Allow manual publishing with a keyboard shortcut
[ https://issues.apache.org/jira/browse/SLING-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3963: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Allow manual publishing with a keyboard shortcut > > > Key: SLING-3963 > URL: https://issues.apache.org/jira/browse/SLING-3963 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > When automatic publishing is disabled it would be nice to be able to quickly > publish a batch of changes by using a keyboard shortcut. Currently this is > not possible unless the servers view is open and the server is selected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3033) [Tooling] differentiate between internal/embedded and externally (manually) started server
[ https://issues.apache.org/jira/browse/SLING-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3033: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [Tooling] differentiate between internal/embedded and externally (manually) > started server > -- > > Key: SLING-3033 > URL: https://issues.apache.org/jira/browse/SLING-3033 > Project: Sling > Issue Type: New Feature > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Differentiate between two kinds of servers: > * eclipse-internal ones: those are started/stopped by eclipse in the servers > view > * eclipse-external ones: those are started manually by the user outside of > eclipse (the more frequent use case probably) > Reflect this differentiation in the UI accordingly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3684) Executed commands should expose the fine-grained operations that have been performed
[ https://issues.apache.org/jira/browse/SLING-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3684: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Executed commands should expose the fine-grained operations that have been > performed > > > Key: SLING-3684 > URL: https://issues.apache.org/jira/browse/SLING-3684 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Robert Munteanu >Priority: Critical > Fix For: Sling Eclipse IDE 1.2.4 > > > Some commands, notably the AddOrUpdateNodeCommand, start having a lot of > logic and can potentially perform many operations, like reodering, child node > deletion and creation. > These operations are now opaque and only visible using debug tracing. > Recording these operations and making them available to the invoker would > serve at least two purposes: > # More detailed logging of what is changed ( for both users and developers ) > # Reconciling the local workspace with changes from the remote repository -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-5652) Publishing content fails if intermediate nodes are not present in the repository
[ https://issues.apache.org/jira/browse/SLING-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5652: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Publishing content fails if intermediate nodes are not present in the > repository > > > Key: SLING-5652 > URL: https://issues.apache.org/jira/browse/SLING-5652 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.1.0 >Reporter: Graham >Assignee: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > Attachments: SLING-5652-aem-access-logs.txt, > SLING-5652-aem-console-logs.txt, sling5652.zip > > > I'm seeing the issue https://issues.apache.org/jira/browse/SLING-3586 with > Sling Eclipse IDE 1.1.0 > The error is > Failed exporting: JcrResult[ success:false, exception: > org.apache.sling.ide.transport.RepositoryException - > javax.jcr.RepositoryException: No parent found at > /content/sling5652/en/thankyou/jcr:content/image/file ; it's needed to create > node at /content/sling5652/en/thankyou/jcr:content/image/file/jcr:content] > Is it possible that this has creeped back in? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6092) Create OSGi-only development feature
[ https://issues.apache.org/jira/browse/SLING-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-6092: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Create OSGi-only development feature > > > Key: SLING-6092 > URL: https://issues.apache.org/jira/browse/SLING-6092 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > For some scenarios - mostly backend-only work - it can be useful to install a > stripped down variation of the IDE Tooling which only provides the OSGi > support for publishing bundles and debugging. > Splitting off the code into a new feature and probably a new bundle should > not be too hard, but we need to handle the upgrade scenario so that when > upgrading to a post-split version all required bundles are installed. > Also, the Eclipse Marketplace listing would need to be updated to make the > new feature a mandatory one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7278) Unable to synchronize files (nt:file) with mix:language added.
[ https://issues.apache.org/jira/browse/SLING-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7278: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Unable to synchronize files (nt:file) with mix:language added. > -- > > Key: SLING-7278 > URL: https://issues.apache.org/jira/browse/SLING-7278 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.1.0 > Environment: Version: Oxygen.1a Release (4.7.1a) > Build id: 20171005-1200 >Reporter: Ivo Leitão >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > Attachments: bug01.png, bug02.png, bug03.png, bug04.png > > > Hello, > I'm trying to use per documentation > https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html > the new i18n dictionary support. > I've created the node with composum as described in the documentation. To be > completely sure that I'm creating the correct structure I've taken a look at > the tests on > https://github.com/apache/sling-org-apache-sling-i18n/blob/master/src/test/java/org/apache/sling/i18n/impl/JcrResourceBundleTest.java, > namely the test_json_dictionary test. > After the creation of the file I'm unable to synchronize it via the sling > support. I've also forced through the creation of the xml file but that gives > me an error synchronizing. > For some reason nt:file's with mix:language added are not synchronizing. > Best Regards, > Ivo Leitão -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-5648) Make Non-Eclipse Module regular Maven Packages
[ https://issues.apache.org/jira/browse/SLING-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5648: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Make Non-Eclipse Module regular Maven Packages > -- > > Key: SLING-5648 > URL: https://issues.apache.org/jira/browse/SLING-5648 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.10 >Reporter: Andreas Schaefer >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Non Eclipse modules like api, artifacts, imll-resource, impl-vlt should be > regular Maven packages (jar) instead of eclipse plugins (eclipse-plugin) to > support development of it by other IDEs like IntelliJ IDEA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4457) ContentDeploymentTest.fileDeployedBeforeAddingModuleToServerIsPublished failed on Jenkins
[
https://issues.apache.org/jira/browse/SLING-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4457:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> ContentDeploymentTest.fileDeployedBeforeAddingModuleToServerIsPublished
> failed on Jenkins
> -
>
> Key: SLING-4457
> URL: https://issues.apache.org/jira/browse/SLING-4457
> Project: Sling
> Issue Type: Test
> Components: IDE
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> *Error Message*
> {noformat}FailOnUnsuccessfulEventsRule : 1 unexpected events captured:
> ReorderChildNodesCommand -> /test/hello.txt : JcrResult[ success:false,
> exception: org.apache.sling.ide.transport.RepositoryException -
> javax.jcr.RepositoryException: Unable to retrieve NodeInfo for
> http://localhost:44686/server/default/jcr%3aroot/]{noformat}
> *Stacktrace*
> {noformat}java.lang.AssertionError: FailOnUnsuccessfulEventsRule : 1
> unexpected events captured:
> ReorderChildNodesCommand -> /test/hello.txt : JcrResult[ success:false,
> exception: org.apache.sling.ide.transport.RepositoryException -
> javax.jcr.RepositoryException: Unable to retrieve NodeInfo for
> http://localhost:44686/server/default/jcr%3aroot/]
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.sling.ide.test.impl.helpers.AbstractFailOnUnexpectedEventsRule.after(AbstractFailOnUnexpectedEventsRule.java:102)
> at
> org.apache.sling.ide.test.impl.helpers.AbstractFailOnUnexpectedEventsRule$1.evaluate(AbstractFailOnUnexpectedEventsRule.java:58)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
> at
> org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:91)
> at
> org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.runTests(AbstractUITestApplication.java:44)
> at
> org.eclipse.e4.ui.internal.workbench.swt.E4Testable$1.run(E4Testable.java:72)
> at java.lang.Thread.run(Thread.java:662){noformat}
> Recorded failures:
> * sling-ide-1.6 build 228
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-3862) Publish operation fails if the bundle to be updated is starting or stopping
[ https://issues.apache.org/jira/browse/SLING-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3862: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Publish operation fails if the bundle to be updated is starting or stopping > --- > > Key: SLING-3862 > URL: https://issues.apache.org/jira/browse/SLING-3862 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > If the bundle that is to be updated is slow to start and is deployed multiple > times in a short interval, the subsequent operations will fail, with a > message similar to > Failed installing bundle : Unable to install/update bundle from dir > /location/target/classes : Bundle some.bundle [377] cannot be update, since > it is either starting or stopping. > Unable to install/update bundle from dir /location/target/classes : Bundle > some.bundle [377] cannot be update, since it is either starting or stopping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3980) Reordering values in a multi value properties from the UI
[ https://issues.apache.org/jira/browse/SLING-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3980: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Reordering values in a multi value properties from the UI > - > > Key: SLING-3980 > URL: https://issues.apache.org/jira/browse/SLING-3980 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Catalin Buzoiu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > Currently it is not possible to re-order the values in a mvp from the uI, one > needs to manually edit the .content.xml file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-5268) Make Sling Connector IDE Independent
[ https://issues.apache.org/jira/browse/SLING-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5268: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Make Sling Connector IDE Independent > > > Key: SLING-5268 > URL: https://issues.apache.org/jira/browse/SLING-5268 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Andreas Schaefer >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Sling Connector code in the IDE Tooling needs to be IDE independent to make > it possible to be used in other IDEs like IntelliJ, NetBeans etc. There are > two main areas: > 1) Modules should not contain OSGi references as for example IntelliJ does > not use OSGi internally. IDE can wrap a module inside OSGi but shouldn't > require it. > 2) Code that is used to check or deploy resources on Sling should be IDE > independent. For example ResourceChangeCommandFactory should not be using > I-classes from Eclipse but rather Interfaces that can be implemented by any > IDE to their requirements. > The main reason for doing this is to ease the adoption of new code from this > project as well as making it easier for new IDE to adopt. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4017) Maintain a mapping of full coverage aggregates
[ https://issues.apache.org/jira/browse/SLING-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4017: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Maintain a mapping of full coverage aggregates > -- > > Key: SLING-4017 > URL: https://issues.apache.org/jira/browse/SLING-4017 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > When deleting it's impossible to know whether an something.xml file was a > full coverage aggregate or an actual XML file. In most places we assume that > it was a full coverage aggregate, but that's not always correct. > We should maintain a mapping of such files as we encounter them and use that > information when a file is deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3775) Review allowed-children node type check
[
https://issues.apache.org/jira/browse/SLING-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3775:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Review allowed-children node type check
> ---
>
> Key: SLING-3775
> URL: https://issues.apache.org/jira/browse/SLING-3775
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Reporter: Stefan Egli
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> SLING-3774 describes a case where a cq:ClientLibraryFolder did not accept a
> sling:Folder as a child - hence preventing a node type change to the latter.
> This needs to be reviewed, as to why
> ntManager.isAllowedPrimaryChildNodeType("cq:ClientLibraryFolder",
> "sling:Folder") would return false..
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-5618) Make the ResourceChangeCommandFactory independent from Eclipse
[ https://issues.apache.org/jira/browse/SLING-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5618: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Make the ResourceChangeCommandFactory independent from Eclipse > -- > > Key: SLING-5618 > URL: https://issues.apache.org/jira/browse/SLING-5618 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Andreas Schaefer >Assignee: Robert Munteanu >Priority: Major > Labels: pull > Fix For: Sling Eclipse IDE 1.2.4 > > > This is a pull request for my changes to Sling IDE Tooling that provides an > Eclipse Independent version of the Resource Command Factory. This is a > separate implementation which does not affect any Eclipse code. > In addition I added an exclusion for the IntelliJ Modules (.iml) to the > parent pom to make the RAT plugin happy. > I merged my changes against the Trunk of yesterday. > Pull Request: https://github.com/apache/sling/pull/130 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4043) The JCR properties view does not display escaped properties with escaped values correctly
[
https://issues.apache.org/jira/browse/SLING-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4043:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> The JCR properties view does not display escaped properties with escaped
> values correctly
> -
>
> Key: SLING-4043
> URL: https://issues.apache.org/jira/browse/SLING-4043
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> Consider a property serialized as
> {noformat}org.apache.sling.commons.log.pattern="\{0,date,-MM-dd
> HH:mm:ss.SSS} {4} [{3}] {5}"{noformat}
> The value displayed by the JCR properties view is {noformat}{4} [{3}]
> {5}{noformat}, while the value displayed when editing is
> {noformat}\{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}
> In fact, both the display and edit modes should work with the unescaped value
> {noformat}{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-6571) Include automatic error reporting
[ https://issues.apache.org/jira/browse/SLING-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-6571: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Include automatic error reporting > - > > Key: SLING-6571 > URL: https://issues.apache.org/jira/browse/SLING-6571 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > The automated error reporting project used by the Eclipse Foundation ( see > https://blog.ctrlflow.com/byo-aeri-in-eclipse-neon/ for some backgroud ) has > now been opened up for all third party developers, allowing them to gather > error reports and store them on a central instance. > This would be very useful in allowing us to quickly understand what problems > occur when the plug-ins are used and getting to reach users faster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-2666) Resource transport layer - checking out resources fails if the DefaultGetServlet does not serve the content
[ https://issues.apache.org/jira/browse/SLING-2666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-2666: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Resource transport layer - checking out resources fails if the > DefaultGetServlet does not serve the content > --- > > Key: SLING-2666 > URL: https://issues.apache.org/jira/browse/SLING-2666 > Project: Sling > Issue Type: Bug > Components: IDE >Reporter: Antonio Sanso >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > see discussion at [0] > [0] http://sling.markmail.org/message/rsmysnx6ombk4u4s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4037) AddOrUpdateNodeCommandTest should connect to the repository via WebDAV remoting
[ https://issues.apache.org/jira/browse/SLING-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4037: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > AddOrUpdateNodeCommandTest should connect to the repository via WebDAV > remoting > --- > > Key: SLING-4037 > URL: https://issues.apache.org/jira/browse/SLING-4037 > Project: Sling > Issue Type: Test > Components: IDE, Testing >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > I've seen some minor differences in behaviour between accessing the > repository directly and accesing via WebDAV remoting, especially related to > node type changes. > To make sure our tests exercise the same code paths, they should use the same > access mechanism. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3629) Provide an XML formatter for content.xml files
[ https://issues.apache.org/jira/browse/SLING-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3629: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Provide an XML formatter for content.xml files > -- > > Key: SLING-3629 > URL: https://issues.apache.org/jira/browse/SLING-3629 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > When editing resource properties through the JCR properties view, we format > the corresponding XML according to the vault canonical format. At the same > time, there is no such provision for working with content.xml files directly > in the editor. > While I don't think that we should format them automatically, it would be > useful to have a formatter which can be manually invoked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3132) [Tooling] provide a filter.xml editor separate and/or as part of the import-content wizard
[ https://issues.apache.org/jira/browse/SLING-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3132: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [Tooling] provide a filter.xml editor separate and/or as part of the > import-content wizard > -- > > Key: SLING-3132 > URL: https://issues.apache.org/jira/browse/SLING-3132 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > As a follow-up of SLING-2984: provide an editor of the filter.xml either > separate and/or as part of the import-content-wizard. That would allow to > import multiple paths in one go in the import-content-wizard. (This > filter.xml-editing would also go hand-in-hand with the "re-import" > button/action.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3089) Investigate using the same model between the repository sync and the Sling (JCR) content provider
[ https://issues.apache.org/jira/browse/SLING-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3089: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Investigate using the same model between the repository sync and the Sling > (JCR) content provider > - > > Key: SLING-3089 > URL: https://issues.apache.org/jira/browse/SLING-3089 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > If we use the same data model we can benefit from the same code base. Right > now there's some duplication and we potentially miss fixes from one area from > another. For instance, the content provider does not yet support properties > stored in $(nodeName).dir/.content.xml files. > Also, it would help in formalizing the SerializationManager API even more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4091) Non-Java content is not deployed if the connection is made in debug mode
[ https://issues.apache.org/jira/browse/SLING-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4091: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Non-Java content is not deployed if the connection is made in debug mode > > > Key: SLING-4091 > URL: https://issues.apache.org/jira/browse/SLING-4091 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.4 >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > If we connect to the server in debug mode we rely on the debug connection to > update changes to Java files. This means that changes to non-java files, e.g. > content files deployed with the JCR content loader will not be published. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3587) Publish not triggered by WST on folder creation
[ https://issues.apache.org/jira/browse/SLING-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3587: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Publish not triggered by WST on folder creation > --- > > Key: SLING-3587 > URL: https://issues.apache.org/jira/browse/SLING-3587 > Project: Sling > Issue Type: Bug > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > When you create a folder in a directory that is hooked up to a (WST)server, > the corresponding publish mechanism doesn't get triggered. > The core issue seems to be a WST-bug IMHO: the > org.eclipse.wst.server.core.internal.ResourceManager.getPublishRequiredServers's > IResourceDeltaVisitor.visit() only returns true if anything related to an > IFile has changed. If a folder has changed, it will navigate down to that > folder, but won't necessarily find anything changed below there and thus > ignore the change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3556) The Filter API should work on resources, not on filesystem-based paths
[ https://issues.apache.org/jira/browse/SLING-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3556: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > The Filter API should work on resources, not on filesystem-based paths > -- > > Key: SLING-3556 > URL: https://issues.apache.org/jira/browse/SLING-3556 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > Attachments: SLING-3556-wip-1.patch > > > Today the SlingLaunchpadBehaviour encapsulates lot of knowledge about what it > takes to find out if a resource should be filtered or not ( also visited in > the context of SLING-3122 ). This knowledge should be rooted in the Filter > API, which currently takes paths. > Instead, it should take a ResourceProxy instance, and delegate to the > SerializationKindManager to see what the serialization policy is, so that it > can determine the repository path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6188) Improve validators
[ https://issues.apache.org/jira/browse/SLING-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-6188: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Improve validators > -- > > Key: SLING-6188 > URL: https://issues.apache.org/jira/browse/SLING-6188 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.1.0 >Reporter: Konrad Windszus >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Both validators being provided by Sling IDE (checking manifest.mf consistency > as well as checking for a valid jcr_root) are not classical WST validators > bound to a specific file. > E.g. manifest.mf can become invalid if one of the referenced service.xmls > vanishes during the build. So it is hard to tell which modifications require > a revalidation. For the content package validation it is currently triggered > only once per validation run (still too often) but not filtered on any > specific files. > I would rather propose to not use WST validators for those cases but rather > do that check only once after each build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-5649) Non-Eclipse Modules should not depend on Eclipse Depedencies
[ https://issues.apache.org/jira/browse/SLING-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5649: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Non-Eclipse Modules should not depend on Eclipse Depedencies > > > Key: SLING-5649 > URL: https://issues.apache.org/jira/browse/SLING-5649 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.10 >Reporter: Andreas Schaefer >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Currently modules like api, artifacts, imll-resource, impl-vlt have their > depends obtained using Tycho which depends on the supported Eclipse version. > Other IDEs like IntelliJ IDEA cannot handle that and so development is > difficult and time consuming. > Also other IDEs that do not use OSGi might have an issue when Eclipse version > changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4034) ListTreeCommand should not use the EventAdmin directly
[ https://issues.apache.org/jira/browse/SLING-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4034: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > ListTreeCommand should not use the EventAdmin directly > -- > > Key: SLING-4034 > URL: https://issues.apache.org/jira/browse/SLING-4034 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > The ListTreeCommand uses the EventAdmin directly for logging, but it should > be wrapped by a TracingCommand instead. That would bring the benefit of not > logging a lot of command executions when connecting to the server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4427) Inneficient JcrNode.hashCode and equals
[
https://issues.apache.org/jira/browse/SLING-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4427:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Inneficient JcrNode.hashCode and equals
> ---
>
> Key: SLING-4427
> URL: https://issues.apache.org/jira/browse/SLING-4427
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.4
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> On certain paths, JcrNode equals and hashcode perform copies of the their
> domElement, manipulate them and use them for equals/hashCode computations,
> e.g.
> {code:java} Element domElementCopy = domElement.copy();
> domElementCopy.clearChildren();
> Element otherDomElementCopy = other.domElement.copy();
> otherDomElementCopy.clearChildren();
> return
> domElementCopy.toString().equals(otherDomElementCopy.toString());{code}
> This has the potential to be quite expensive and should be corrected
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-3627) Create warnings for resources under the content sync root which are not covered by filter.xml
[ https://issues.apache.org/jira/browse/SLING-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3627: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Create warnings for resources under the content sync root which are not > covered by filter.xml > - > > Key: SLING-3627 > URL: https://issues.apache.org/jira/browse/SLING-3627 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > Entries created in the local workspace but not covered by the filter.xml > definition are a cause of confusion, since they are not synchronized to the > remote repository with no warning/error raised about this. > We should create warnings for such files. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6462) Filter Isolated jcr:content nodes (by includes) are not deployed
[
https://issues.apache.org/jira/browse/SLING-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6462:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Filter Isolated jcr:content nodes (by includes) are not deployed
>
>
> Key: SLING-6462
> URL: https://issues.apache.org/jira/browse/SLING-6462
> Project: Sling
> Issue Type: Bug
> Components: Tooling
> Environment: MacOS Sierra, JDK 1.8, latest Sling
>Reporter: Andreas Schaefer
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: SLING-6462.zip
>
>
> If a jcr:content node is included by a filter.xml but not its parent then the
> deployment of the corresponding .content.xml fails and with it its parent
> node becomes a Sling Folder and the jcr:content node is missing.
> Assuming we have the following on our file system:
> - A folder /etc/designs/base
> - A file .content.xml in that folder:
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0";
> xmlns:cq="http://www.day.com/jcr/cq/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0";
> jcr:primaryType="cq:Page">
> cq:doctype="html_5"
> cq:template="/libs/wcm/core/templates/designpage"
> jcr:primaryType="cq:PageContent"
> jcr:title="AEM Base Components"
> sling:resourceType="wcm/core/components/designer"/>
>
> {code}
> A filter.xml:
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> Taking out the include filter and replace it with the comment out one below
> makes the deployment work.
> Some preliminary investigations revealed that the
> ResourceChangeCommandFactory.getFilterResult() returns
> PREREQUISITE instead of ALLOW as the path that is tested is /etc/designs/base
> instead of /etc/designs/base/jcr:content.
> Locally I added that code after the filter.filter() call and before the
> return:
> {code:java}
> //AS NOTE: If we have a jcr:content and it is limited by an include then it
> might fail
> //AS NOTE: (DENY) or worse coming back as PREREQUISITE making an undefined
> node. Here it
> //AS NOTE: checks if the resource proxy has a child of jcr:content and if so
> check with
> //AS NOTE: that path.
> if(filterResult != FilterResult.ALLOW && resourceProxy != null) {
> List resourceProxyChildren = resourceProxy.getChildren();
> if(resourceProxyChildren.size() == 1) {
> ResourceProxy child = resourceProxyChildren.get(0);
> if(child.getPath().endsWith("/jcr:content")) {
> FilterResult temp = filter.filter(child.getPath());
> if(temp == FilterResult.ALLOW) {
> return FilterResult.ALLOW;
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-6342) Sling IDE: Better deal with reconfigurations of the sling repository service
[
https://issues.apache.org/jira/browse/SLING-6342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6342:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Sling IDE: Better deal with reconfigurations of the sling repository service
>
>
> Key: SLING-6342
> URL: https://issues.apache.org/jira/browse/SLING-6342
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> In some cases, e.g. deployment of a configuration for PID
> {{org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl}} the
> sling repository service is restarted in the background which leads to
> temporary failures during publishing like this
> {code}
> Failed publishing path=/content, result=JcrResult[ success:false, exception:
> org.apache.sling.ide.transport.RepositoryException -
> javax.jcr.RepositoryException: AuthenticationSupport service missing. Cannot
> authenticate request.]
> {code}
> The publish client code should check in advance if the relevant
> bundles/services are running.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-4030) Create test for creating resources with missing parents while server is stopped
[ https://issues.apache.org/jira/browse/SLING-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4030: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Create test for creating resources with missing parents while server is > stopped > --- > > Key: SLING-4030 > URL: https://issues.apache.org/jira/browse/SLING-4030 > Project: Sling > Issue Type: Test > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.4 >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > The scenario covered in SLING-3586 and detailed in > https://issues.apache.org/jira/browse/SLING-3586?focusedCommentId=14166984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14166984 > should be covered by a regression test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3581) Consider prompting the user about uninstalling a bundle/content project when removed from the server
[ https://issues.apache.org/jira/browse/SLING-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3581: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Consider prompting the user about uninstalling a bundle/content project when > removed from the server > > > Key: SLING-3581 > URL: https://issues.apache.org/jira/browse/SLING-3581 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > Currently, when removing a bundle or content project from the server they are > not uninstalled. This can be surprising, but also when deleting all related > data from the repository can be surprising. > Let's considering adding using a dialog and maybe a per-workspace preference > ( or per-server? ) for controlling this behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6344) Support filter.xmls being generated by the content-package-maven-plugin
[
https://issues.apache.org/jira/browse/SLING-6344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6344:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Support filter.xmls being generated by the content-package-maven-plugin
> ---
>
> Key: SLING-6344
> URL: https://issues.apache.org/jira/browse/SLING-6344
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: SLING-6344-v01.patch, SLING-6344-v02.patch,
> SLING-6344-v03.patch
>
>
> The content-package-maven plugin can not only consume a filter.xml from the
> source directory, but also generate or merge filter.xmls. Therefore Sling IDE
> should consider only the filter.xml in the generated artifacts (package). The
> problem with that is, that content-package-maven-plugin does only generate
> that filter.xml when it generates the real package.
> There is one other related issue: In case a filter file is not found, the
> method {{ResourceChangeCommandFactory#getFilterResult}} returns {{ALLOW}}
> while it should return {{DENY}} to not overwrite any nodes in case the filter
> rules could not be determined.
> In my case those two problems lead to a modification of the jcr:primaryType
> of the root node in the JCR from {{rep:root}} to {{nt:unstructured}} and the
> resourceType from {{sling:redirect}} to just being removed which breaks the
> redirect handling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-3827) Unable to create nodes with protected properties, e.g. rep:User
[
https://issues.apache.org/jira/browse/SLING-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3827:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Unable to create nodes with protected properties, e.g. rep:User
> ---
>
> Key: SLING-3827
> URL: https://issues.apache.org/jira/browse/SLING-3827
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.4
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> I tried to create a user using the tooling, and I get back an exception:
> The debug trace is
> {noformat}
> | Worker-886 | 2014-08-06 18:10:22.590 | org.apache.sling.ide.impl-vlt |
> /debug | org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand | update | 96 |
> Created node at /home/users/system/blabla with primaryType rep:User |
> | Worker-886 | 2014-08-06 18:10:22.591 | org.apache.sling.ide.impl-vlt |
> /debug | org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand | updateMixins
> | 347 | Added new mixin rep:AccessControllable to node at path
> /home/users/system/blabla |
> | Worker-886 | 2014-08-06 18:10:22.591 | org.apache.sling.ide.impl-vlt |
> /debug | org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand | updateNode |
> 298 | Setting property rep:principalName with value
> org.apache.jackrabbit.spi.commons.value.QValueValue@b7c2c87f (raw =
> mcm-service) on node at /home/users/system/blabla |
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-3780) Enrich the ResourceProxy model to hold more information about the property metadata
[
https://issues.apache.org/jira/browse/SLING-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3780:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Enrich the ResourceProxy model to hold more information about the property
> metadata
> ---
>
> Key: SLING-3780
> URL: https://issues.apache.org/jira/browse/SLING-3780
> Project: Sling
> Issue Type: Improvement
> Components: IDE
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> At the moment the ResourceProxy holds a plain {{Map}} for its
> properties. As a start, it has worked pretty well. However, it leads to code
> that is a bit convoluted and not correct.
> For instance, we have instanceof checks to determine the property type and
> multiplicity. And we probably fails to distinguish between a {{REFERENCE}}
> and a {{WEAKREFERENCE}} property, or a {{STRING}} and {{NAME}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-4115) Optimise rename handling
[ https://issues.apache.org/jira/browse/SLING-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4115: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Optimise rename handling > > > Key: SLING-4115 > URL: https://issues.apache.org/jira/browse/SLING-4115 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.4 >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > A rename operation is translated right now into a bulk delete ( see > SLING-3607 for delete optimisations ) and a bulk add. If the rename is > peformed for a resource with lots of children, this is very inefficient. > We should be able to detect such occurences and translate them into a single > RenameOperation which, in case of the vlt-based implementation, delegates to > Session#move(String, String) . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3131) [Tooling] consider raising 'sling console' into its own view
[ https://issues.apache.org/jira/browse/SLING-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3131: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [Tooling] consider raising 'sling console' into its own view > > > Key: SLING-3131 > URL: https://issues.apache.org/jira/browse/SLING-3131 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > The 'Sling Console' becomes a rather central tool as it will allow to see > what is synched between the eclipse workspace and a sling instance. > Currently, it is accessible as a type of console in the normal Console view. > This sort of 'hides' it though - as you can only have one view of the stacked > Console view open at a time. We could consider moving the Sling Console into > its own, separate view (or allow both?), that way also making it more visible > (it will be listed as a separate view, which people might more likely > discover than another type of console) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3644) Improve handling of binary properties outside nt:file file nodes
[ https://issues.apache.org/jira/browse/SLING-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3644: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Improve handling of binary properties outside nt:file file nodes > > > Key: SLING-3644 > URL: https://issues.apache.org/jira/browse/SLING-3644 > Project: Sling > Issue Type: Bug > Components: IDE >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Currently ( see SLING-3609 ) we ignore binary properties which don't belong > to nt:file nodes. We should be able to recognize them and update them as > needed. > We probably need > * a new property type which points to the binary written on disk > * a way of ignoring these files so we don't recognize them as nt:file nodes > See also the [VaultFS docs on Binary > Properties|https://jackrabbit.apache.org/filevault/vaultfs.html#Binary_Properties] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4045) Lack of support for multi-facet (content and bundle) projects
[
https://issues.apache.org/jira/browse/SLING-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4045:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Lack of support for multi-facet (content and bundle) projects
> -
>
> Key: SLING-4045
> URL: https://issues.apache.org/jira/browse/SLING-4045
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Kamil Ciecierski
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: aemtools.zip
>
>
> I am working on the project which is +not based+ on
> com.adobe.granite.archetype: sample-project-archetype. My project also
> contains multiple module projects, but some of them contain both java and jsp
> files under paths:
> * java files: _/src/main/java//..._
> * jsp files: _/src/main/aem// etc>/..._
> Basically it looks like merged _core_ module and _ui.apps_ module from _AEM
> Sample Multi-Module Project_/
> When I configure my module as "Content Project" the *jsp* files are uploaded
> to the server automatically, but the plugin does not respond on *java* files
> changes.
> When I configure my module as "Bundle Project" the *java* files are uploaded
> to the server automatically, but the plugin does not respond on *jsp* files
> changes.
> I've also tested converting project to Faceted Form by doing:
> * Right click on module project and choosing _Configure/Convert to Faceted
> Form_
> * Choosing _Content module_ and _Bundle module_ from _Project facet list_
> * Clicking Apply and OK.
> After this _org.eclipse.wst.common.project.facet.core.xml_ is generated under
> the path: _/.settings_ which looks like this:
> {code}
>
>
>
>
>
> {code}
> After this if I start editing *jsp* files at first then the content files are
> uploaded to server but *java* uploading isn't working - I see _ JcrResult[
> success:true]_ in Sling logs.
> If I start editing *java* files at first then the java files are uploaded to
> server, but *jsp* uploading isn't working - I see logs that _target\classes_
> is uploaded_.
> I conclusion, I can't make plugin to work correctly with the modules
> containing both jsp and java files. I also don't know if you planned the
> support for this kind of projects or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-6242) Sling IDE: Include source bundles/features in our p2 repo
[ https://issues.apache.org/jira/browse/SLING-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-6242: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Sling IDE: Include source bundles/features in our p2 repo > - > > Key: SLING-6242 > URL: https://issues.apache.org/jira/browse/SLING-6242 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.1.0 >Reporter: Konrad Windszus >Assignee: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > Attachments: SLING-6242.diff > > > Currently the aggregating source bundle is decoupled from the artifacts in > the p2 repo (see > http://sling.staging.apache.org/documentation/development/release-management.html#releasing-the-sling-ide-tooling, > step 9) as well as from the tycho build. Although this big source bundle may > necessary for ASF it would be helpful for the users to allow to install the > sources through the p2 repo as well. Some hints on how to achieve that are > available in > https://www.eclipse.org/tycho/sitedocs-extras/tycho-source-feature-plugin/source-feature-mojo.html > and > https://eclipse.org/tycho/sitedocs/tycho-source-plugin/plugin-source-mojo.html. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3128) [Tooling] evaluate filter.xml in content-browser: mark nodes if they're not included
[ https://issues.apache.org/jira/browse/SLING-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3128: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [Tooling] evaluate filter.xml in content-browser: mark nodes if they're not > included > > > Key: SLING-3128 > URL: https://issues.apache.org/jira/browse/SLING-3128 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > In the slingclipse content-browser, evaluate the filter.xml to mark nodes > that are not included in the filter.xml and thus not synched automatically: > decorate those not included in some way or form visually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4667) Allow usage of the Sling IDE tooling in OSGi-only environments
[
https://issues.apache.org/jira/browse/SLING-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4667:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Allow usage of the Sling IDE tooling in OSGi-only environments
> --
>
> Key: SLING-4667
> URL: https://issues.apache.org/jira/browse/SLING-4667
> Project: Sling
> Issue Type: New Feature
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.6
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: SLING-4667-poc.diff
>
>
> The IDE tooling is quite usable for OSGi-only development on top of Apache
> Sling. However, the tooling always connects to the repository at startup:
> {code:java}Command command =
> repository.newListChildrenNodeCommand("/");{code}
> We should have a more fine-grained approach and support environments where
> the JCR webdav entry point is not available.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-4191) Support resolving JSP scripts from the repository
[
https://issues.apache.org/jira/browse/SLING-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4191:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Support resolving JSP scripts from the repository
> -
>
> Key: SLING-4191
> URL: https://issues.apache.org/jira/browse/SLING-4191
> Project: Sling
> Issue Type: New Feature
> Components: IDE
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> A common pattern in Sling applications is to define several taglibs and
> imports in a globally included file and reference it from all JSPs, e.g.
> {code}<%@include file="/libs/foundation/global.jsp"%>{code}
> These files aren't part of the project checkout so the JSP editor will raise
> an error and is not able to provide auto-completion based on that global.jsp
> file.
> We should be able to load these files from the repository, although it
> remains to be seen what we can do that:
> - is fast
> - stays in sync with changes in the repository initiated from other sources
> - has an a well-defined and intuitive behaviour when the repository is not
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-5650) Extract Common Code into a Framework with IDE hooks
[ https://issues.apache.org/jira/browse/SLING-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5650: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Extract Common Code into a Framework with IDE hooks > --- > > Key: SLING-5650 > URL: https://issues.apache.org/jira/browse/SLING-5650 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.10 >Reporter: Andreas Schaefer >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Module Deployment, Support Bundle installation etc is a mixture of IDE and > Non-IDE code. It would be great to extract the Non-IDE code into a Framework > that provides hooks for IDEs to integrate. > The current IntelliJ Sling IDE plugin has a prototype to illustrate that but > is not truly IDE independent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3611) Allow users to specify custom archetypes for the Sling bundle project
[ https://issues.apache.org/jira/browse/SLING-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3611: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Allow users to specify custom archetypes for the Sling bundle project > - > > Key: SLING-3611 > URL: https://issues.apache.org/jira/browse/SLING-3611 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > As requested by [~kwin], we should allow users to contribute maven archetype > coordinates to be used by the new sling bundle project wizard. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3607) Resource deletion can delete too much
[ https://issues.apache.org/jira/browse/SLING-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3607: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Resource deletion can delete too much > - > > Key: SLING-3607 > URL: https://issues.apache.org/jira/browse/SLING-3607 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > There are two issue with the deletion code: > * it deletes .content.xml files > * it deletes everything under a subtree, even though it would be enough to > just delete the subtree root -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3759) Support viewing/tailing logs for a defined Sling server
[ https://issues.apache.org/jira/browse/SLING-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3759: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Support viewing/tailing logs for a defined Sling server > --- > > Key: SLING-3759 > URL: https://issues.apache.org/jira/browse/SLING-3759 > Project: Sling > Issue Type: New Feature > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > It would be very useful to be able to directly inspect / tail the logs of the > Sling runtime instance from a dedicated Eclipse view. > We should be able to infer the location if we know that the instance is > local, but that probably requires a bit of infrastructure work to be able to > distinguish local/remote instances. > For an example involving AEM and a dedicated plugin, see > http://labs.sixdimensions.com/blog/2014-07-07/tailing-aem-logs-in-eclipse/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3585) Wizard for creating a new simple OSGi bundle
[ https://issues.apache.org/jira/browse/SLING-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3585: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Wizard for creating a new simple OSGi bundle > > > Key: SLING-3585 > URL: https://issues.apache.org/jira/browse/SLING-3585 > Project: Sling > Issue Type: New Feature > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > (Created as a spin-off from SLING-3174). > We should support a simple bundle project which does not require Maven for > execution. Open questions > * how do we resolve the needed jars in order to add them to the classpath? > * what sort of content do we add to the project? A service using DS > annotations is out since we don't have the proper builder installed to > generate the XML descriptors -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3733) Remodel API for more natural usage of IO operations
[
https://issues.apache.org/jira/browse/SLING-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3733:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Remodel API for more natural usage of IO operations
> ---
>
> Key: SLING-3733
> URL: https://issues.apache.org/jira/browse/SLING-3733
> Project: Sling
> Issue Type: Improvement
> Components: IDE
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> The current approach for working with I/O is a bit convoluted. To make sure
> we integrate properly with multiple potential environments - Eclipse,
> IntelliJ, Netbeans, CLI - our APIs work mainly with Strings and InputStreams
> ( or byte-arrays ).
> Although it works fine, it's starting to become awkward, as a single
> operation can consist of multiple calls to API methods due to this
> back-and-forth. For instance:
> {code}
> // Sling IDE API
> String serializationFilePath =
> serializationManager.getSerializationFilePath(resourceLocation,
> serializationKind);
>// Eclipse API
> IPath serializationFilePath2 =
> Path.fromPortableString(serializationFilePath);
> // Eclipse API
> IResource serializationResource =
> syncDirectory.findMember(serializationFilePath2);
> // a bit later...
>// Sling IDE API
>serializationManager.readSerializationData(serializationFilePath,
> serializationResource.getContents();
> {code}
> We should overhaul the I/O-based APIs to work with I/O abstractios ( e.g.
> FileReader -> EclipseFileReader ) and make those operations more coherent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM
[ https://issues.apache.org/jira/browse/SLING-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5582: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > DAM Updates fail due to race conditions with Workflows in AEM > - > > Key: SLING-5582 > URL: https://issues.apache.org/jira/browse/SLING-5582 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.10 >Reporter: Andreas Schaefer >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > In my IntelliJ plugin an update of a DAM entry I sometimes run into an > exception while updating rendition files. This seems to be caused by the DAM > Workflows inside AEM which is triggered as soon as the original file is > updated. This is probably due to the fact that the "impl-vlt" code is > committing a change after each and every command and so the workflow is > triggered right away causing problems with the updates of the rendition files. > I would think this is not just an issue of DAM assets but in general an issue > with any node that can trigger a workflow. > From my point of view the plugin should be able to control the commits so > that a logical group like a DAM asset can be update in single step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3591) Unable to delete all nodes of a full coverage aggregate
[ https://issues.apache.org/jira/browse/SLING-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3591: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Unable to delete all nodes of a full coverage aggregate > --- > > Key: SLING-3591 > URL: https://issues.apache.org/jira/browse/SLING-3591 > Project: Sling > Issue Type: Bug > Components: IDE >Reporter: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.2.4 > > > With the fix for SLING-3590 it is no longer possible to delete all nodes of a > full coverage aggregate. Pushing to 1.0.2 since > - it is not an usual scenario > - it requires some changes to the Sling IDE Resource API, which I'd like to > defer for now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3584) Offline-mode for NodeTypeRegistry
[ https://issues.apache.org/jira/browse/SLING-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3584: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Offline-mode for NodeTypeRegistry > - > > Key: SLING-3584 > URL: https://issues.apache.org/jira/browse/SLING-3584 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.0 >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > The current NodeTypeRegistry introduced with SLING-3571 only works when > connected to a running server (as it retrieves the nodetypes under > /jcr:system...). During development a server might not always be running > though and/or you might not want to be connected to it all the time (to > support batch-publishing for example). Therefore I think we should have an > offline-mode for the NodeTypeRegistry (by eg storing the node types in the > .settings directory or similar) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4036) Changing the jcr primary type does not work if mandatory properties are added
[ https://issues.apache.org/jira/browse/SLING-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4036: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Changing the jcr primary type does not work if mandatory properties are added > - > > Key: SLING-4036 > URL: https://issues.apache.org/jira/browse/SLING-4036 > Project: Sling > Issue Type: Bug > Components: IDE >Affects Versions: Sling Eclipse IDE 1.0.2 >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Similar to SLING-4035, but this time use a node type which has at least one > mandatory property. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4455) Streamline UI operations when project is deployed on exactly one server
[ https://issues.apache.org/jira/browse/SLING-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4455: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Streamline UI operations when project is deployed on exactly one server > --- > > Key: SLING-4455 > URL: https://issues.apache.org/jira/browse/SLING-4455 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Critical > Fix For: Sling Eclipse IDE 1.2.4 > > > The WST framework allows a module to be deployed on multiple servers. We > honour this possibility at all times, but I think that most of the times the > module will only be deployed on one server. > If we find out that the module is deployed on exactly one server, we should > no longer show the wizards ( currently the import and export wizard ) but > rather start the action immediately. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3113) [Tooling] make use of control-port for (re)start/stop of a (launchpad) server
[ https://issues.apache.org/jira/browse/SLING-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3113: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > [Tooling] make use of control-port for (re)start/stop of a (launchpad) server > - > > Key: SLING-3113 > URL: https://issues.apache.org/jira/browse/SLING-3113 > Project: Sling > Issue Type: New Feature > Components: IDE >Reporter: Stefan Egli >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > Sling launchpad comes with a control-port, that allows to start/stop/restart > a server (in a separate vm) - details see SLING-2225 and > http://sling.apache.org/documentation/development/embedding-sling.html > Slingclipse should make use of that when controlling the "external" server - > eg for restarting a server. Other use-cases could also be supported (not sure > what though..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6241) Enable Pack200 compression for Sling IDE
[ https://issues.apache.org/jira/browse/SLING-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-6241: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Enable Pack200 compression for Sling IDE > > > Key: SLING-6241 > URL: https://issues.apache.org/jira/browse/SLING-6241 > Project: Sling > Issue Type: Improvement > Components: IDE >Affects Versions: Sling Eclipse IDE 1.1.0 >Reporter: Konrad Windszus >Assignee: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > We should rely on the pack200 compression mechanism for all features/bundles > being contained in our p2 repo. This can be easily achieved with Tycho > according to http://wiki.eclipse.org/Tycho/Pack200. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-3784) Convert majority of eclipse-based tests to test vlt commands or the ResourceChangeCommandFactory
[
https://issues.apache.org/jira/browse/SLING-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3784:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Convert majority of eclipse-based tests to test vlt commands or the
> ResourceChangeCommandFactory
>
>
> Key: SLING-3784
> URL: https://issues.apache.org/jira/browse/SLING-3784
> Project: Sling
> Issue Type: Test
> Components: IDE, Testing
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> The current mechanism for content sync is
> * for reach resource change/build event/manual publish
> * {{SlingContentModuleFactory}} generates lists of module resources
> * Eclipse change detection mechanism generates a diff
> * {{SlingLaunchpadBehaviour}} invokes the {{ResourceChangeCommandFactory}}
> to build vlt commands
> * vlt commands are executed
> The current eclipse-based tests, while useful, exercise the whole process and
> are therefore more brittle and more difficult to write that the alternatives
> testing a smaller part of the stack
> We now have tests in place for each of the steps ( excluding of course
> Eclipse diff generation, but that's out of scope ). Moving the tests to
> simpler fixtures will make the tests more stable, faster and easier to write.
> We should still keep some end-to-end tests, but we will not aim to test all
> scenarios end-to-end.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-4031) Missing MANIFEST.MF should be a validation error
[
https://issues.apache.org/jira/browse/SLING-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4031:
---
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> Missing MANIFEST.MF should be a validation error
>
>
> Key: SLING-4031
> URL: https://issues.apache.org/jira/browse/SLING-4031
> Project: Sling
> Issue Type: Test
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.2.4
>
>
> I just noticed a warning on the Sling console when a bundle was rebuilt
> {quote}[October 11, 2014 2:09:53 AM EEST] InstallBundle ->
> /home/ADOBENET/rmuntean/Downloads/import/myproject/components/target/classes
> : Project P/myproject.components does not have a META-INF/MANIFEST.MF (yet) -
> not publishing this time (0 ms)
> {quote}
> This should be a validation error and block publishing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7391) Adding a namespaced property using the JCR properties view should ensure the namespace is present in the file
[ https://issues.apache.org/jira/browse/SLING-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7391: --- Fix Version/s: (was: Sling Eclipse IDE 1.2.2) Sling Eclipse IDE 1.2.4 > Adding a namespaced property using the JCR properties view should ensure the > namespace is present in the file > - > > Key: SLING-7391 > URL: https://issues.apache.org/jira/browse/SLING-7391 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > ( initially reported at > https://github.com/Adobe-Marketing-Cloud/aem-eclipse-developer-tools/issues/81 > ) > Whenever adding a property using the JCR properties view we should make sure > the namespace is declared in the xml file. We can start by adding a few > well-known prefixes, but most likely we need to infer the known namespaces > from the server. This will not work properly in case the server is not > connected, so in that scenario (or when the namespace is not known probably) > we should report an error to the user and refuse to perform the update. We > should also direct the user to edit the file directly as an alternative. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7518) Deploying a new Sling bundle project from the create bundle wizard fails: Add and remove cannot both be null/empty
[
https://issues.apache.org/jira/browse/SLING-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-7518.
Resolution: Fixed
Fixed in [sling-ide-tooling commit
d59bb679|https://github.com/apache/sling-ide-tooling/commit/d59bb679] .
Problem was that we did not properly detect projects configured with the
{{bnd-maven-plugin}} as bundle projects.
> Deploying a new Sling bundle project from the create bundle wizard fails: Add
> and remove cannot both be null/empty
> --
>
> Key: SLING-7518
> URL: https://issues.apache.org/jira/browse/SLING-7518
> Project: Sling
> Issue Type: Task
> Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.2
>
>
> {noformat}java.lang.IllegalArgumentException: Add and remove cannot both be
> null/empty
> at
> org.eclipse.wst.server.core.internal.Server.canModifyModules(Server.java:2489)
> at
> org.eclipse.wst.server.core.internal.ServerWorkingCopy.modifyModules(ServerWorkingCopy.java:546)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.deployProjectsOnServer(AbstractNewSlingApplicationWizard.java:190)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard$3.execute(AbstractNewSlingApplicationWizard.java:134)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:107)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2214)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:128)
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:437)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:353)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:980)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.performFinish(AbstractNewSlingApplicationWizard.java:130)
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:778)
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:417)
> at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619)
> at
> org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
> at org.eclipse.jface.window.Window.open(Window.java:794)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:115)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
> at
> org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
> at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:681)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:595)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> at
> org.eclipse.equinox.inter
[jira] [Commented] (SLING-7518) Deploying a new Sling bundle project from the create bundle wizard fails: Add and remove cannot both be null/empty
[
https://issues.apache.org/jira/browse/SLING-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377533#comment-16377533
]
Robert Munteanu commented on SLING-7518:
Content projects are not affected, just tried
> Deploying a new Sling bundle project from the create bundle wizard fails: Add
> and remove cannot both be null/empty
> --
>
> Key: SLING-7518
> URL: https://issues.apache.org/jira/browse/SLING-7518
> Project: Sling
> Issue Type: Task
> Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.2
>
>
> {noformat}java.lang.IllegalArgumentException: Add and remove cannot both be
> null/empty
> at
> org.eclipse.wst.server.core.internal.Server.canModifyModules(Server.java:2489)
> at
> org.eclipse.wst.server.core.internal.ServerWorkingCopy.modifyModules(ServerWorkingCopy.java:546)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.deployProjectsOnServer(AbstractNewSlingApplicationWizard.java:190)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard$3.execute(AbstractNewSlingApplicationWizard.java:134)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:107)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2214)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:128)
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:437)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:353)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:980)
> at
> org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.performFinish(AbstractNewSlingApplicationWizard.java:130)
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:778)
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:417)
> at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619)
> at
> org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
> at org.eclipse.jface.window.Window.open(Window.java:794)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:115)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
> at
> org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
> at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:681)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:595)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication
[jira] [Created] (SLING-7518) Deploying a new Sling bundle project from the create bundle wizard fails: Add and remove cannot both be null/empty
Robert Munteanu created SLING-7518:
--
Summary: Deploying a new Sling bundle project from the create
bundle wizard fails: Add and remove cannot both be null/empty
Key: SLING-7518
URL: https://issues.apache.org/jira/browse/SLING-7518
Project: Sling
Issue Type: Task
Components: IDE
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.2.2
{noformat}java.lang.IllegalArgumentException: Add and remove cannot both be
null/empty
at
org.eclipse.wst.server.core.internal.Server.canModifyModules(Server.java:2489)
at
org.eclipse.wst.server.core.internal.ServerWorkingCopy.modifyModules(ServerWorkingCopy.java:546)
at
org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.deployProjectsOnServer(AbstractNewSlingApplicationWizard.java:190)
at
org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard$3.execute(AbstractNewSlingApplicationWizard.java:134)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:107)
at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2214)
at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:128)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:437)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:353)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:980)
at
org.apache.sling.ide.eclipse.ui.wizards.AbstractNewSlingApplicationWizard.performFinish(AbstractNewSlingApplicationWizard.java:130)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:778)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:417)
at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619)
at
org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
at org.eclipse.jface.window.Window.open(Window.java:794)
at
org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:115)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
at
org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5627)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4461)
at
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
at
org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:681)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:595)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAcces
Re: [VOTE] Release Apache Sling Testing Sling Mock 2.2.18, Servlet Helpers 1.1.4
+1 On Mon, 26 Feb 2018 at 12:15 Stefan Seifert wrote: > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > stefan > >
[jira] [Resolved] (SLING-7517) Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7517. --- Resolution: Fixed Fixed with b1ac26cfe2a6b4c6c20bbe30c5d2b3191e8bb5dc > Memory Leak for "fake" Request objects in ModelAdapterFactory with > interface-based models > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7517) Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7517: -- Summary: Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models (was: CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory) > Memory Leak for "fake" Request objects in ModelAdapterFactory with > interface-based models > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7517) CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7517: -- Description: The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). The fix in SLING-7470 was incomplete and only addressed class-based models. Interface-based models were not fixed. was: The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). > CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7517) CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory
Justin Edelson created SLING-7517: - Summary: CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory Key: SLING-7517 URL: https://issues.apache.org/jira/browse/SLING-7517 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.4.6 Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Sling Models Impl 1.4.8 The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Labels: patch-available (was: )
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
> Labels: patch-available
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates a String from a Map where
> the entries are separated by {{,}} i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with a string (with very
> simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
> created with an empty string and then the map should be filled with the
> according put/set methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Comment: was deleted
(was: PR at
https://github.com/apache/sling-org-apache-sling-scripting-sightly/pull/2.)
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
> Labels: patch-available
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates a String from a Map where
> the entries are separated by {{,}} i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with a string (with very
> simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
> created with an empty string and then the map should be filled with the
> according put/set methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377285#comment-16377285
]
ASF GitHub Bot commented on SLING-7516:
---
kwin opened a new pull request #2: SLING-7516 support comma in selectors for
data-sly-resource
URL: https://github.com/apache/sling-org-apache-sling-scripting-sightly/pull/2
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates a String from a Map where
> the entries are separated by {{,}} i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with a string (with very
> simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
> created with an empty string and then the map should be filled with the
> according put/set methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377286#comment-16377286
]
Konrad Windszus commented on SLING-7516:
PR at https://github.com/apache/sling-org-apache-sling-scripting-sightly/pull/2.
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates a String from a Map where
> the entries are separated by {{,}} i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with a string (with very
> simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
> created with an empty string and then the map should be filled with the
> according put/set methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Testing Sling Mock 2.2.18, Servlet Helpers 1.1.4
+1 On Mon, Feb 26, 2018 at 6:24 AM, Stefan Seifert wrote: > +1 > > >
[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout
[
https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377213#comment-16377213
]
Valentin Olteanu commented on SLING-7169:
-
I've committed a working patch in
[PR#7|https://github.com/apache/sling-org-apache-sling-testing-clients/pull/7],
which introduces the
[IndexingClient|https://github.com/volteanu/sling-org-apache-sling-testing-clients/blob/SLING-7169/src/main/java/org/apache/sling/testing/clients/indexing/IndexingClient.java].
I've tried the patch by:
1. pause the async index lange
2. start {IndexingClient#waitForAsyncIndexing()}
3. wait 20s to see if the method returns (should not)
4. resume the lane
5. the method returns after a few seconds
6. repeat for the fulltextasync lane
Note that the patch is based on SLING-7509 and SLING-7511.
The only thing I'm not sure about is whether the queries will always pick the
right index (are they specific enough?). Will need [~tmueller] advice for this.
In total, a call to {{#waitForAsyncIndexing()}} will potentially:
* create index definitions under {{/tmp/test/waitForAsyncIndexing/oak:index}}
* create nodes under {{/tmp/test/waitForAsyncIndexing/content}}
* install a bundle with a jsp exposed as a resource in {{/apps/testQuery}}
* create a node {{/content/testquery}} with the previously created resourceType
* run queries via the previously created resource
[~rombert], do you see any issues with this procedure in the context of 0DT? I
want to have this tool working in all the cases.
> FullTextIndexingTest sometimes fails with a timeout
> ---
>
> Key: SLING-7169
> URL: https://issues.apache.org/jira/browse/SLING-7169
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
>Reporter: Robert Munteanu
>Priority: Major
> Labels: sling-IT
> Attachments: SLING-7169-logs.tar.gz
>
>
> The test fails maybe 1 in 10 runs. I could reproduce this locally by running
> many times. I've also seen it once on Jenkins.
> **Old description below**
> After upgrading the launchpad to commons.threads 3.2.10 the
> FullTextIndexingTest failed ( [build
> 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ).
> I also reproduced it once locally.
> [~kwin] - since the commons.threads release is the potential root cause, can
> you please take a look at the failure and see if it's related?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Description:
Due to the way how the request dispatcher options are serialized into one big
string in
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
you cannot use e.g. selectors which contain a comma. This is a problem because
currently selectors are the only way to propagate parameters from one HTL
script to another script/servlet (compare with SLING-7515).
The method {{createDispatcherOptions}} generates a String from a Map where the
entries are separated by {{,}} i.e. comma. If either the map key or the map
value contain a comma itself the tokenization in
https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
works incorrectly!
Therefore instead of using the constructor with a string (with very
simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
created with an empty string and then the map should be filled with the
according put/set methods.
was:
Due to the way how the request dispatcher options are serialized into one big
string in
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
you cannot use e.g. selectors which contain a comma. This is a problem because
currently selectors are the only way to propagate parameters from one HTL
script to another script/servlet (compare with SLING-7515).
The method {{createDispatcherOptions}} generates from a Map a String where the
entries are separated by {{,}}, i.e. comma. If either the map key or the map
value contain a comma itself the tokenization in
https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
works incorrectly!
Therefore instead of using the constructor with strings (with very
simple/incorrect parsing) you should rather call put for each option separately.
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates a String from a Map where
> the entries are separated by {{,}} i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with a string (with very
> simple/incorrect parsing) the {{RequestDispatcherOptions}} should rather be
> created with an empty string and then the map should be filled with the
> according put/set methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly.
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Summary: ResourceRuntimeExtension: Selectors containing a comma are not
treated correctly. (was: ResourceRuntimeExtension: Modified selectors are
always stripped after a comma.)
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly.
> -
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates from a Map a String where
> the entries are separated by {{,}}, i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with strings (with very
> simple/incorrect parsing) you should rather call put for each option
> separately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7516) ResourceRuntimeExtension: Modified selectors are always stripped after a comma.
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Description:
Due to the way how the request dispatcher options are serialized into one big
string in
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
you cannot use e.g. selectors which contain a comma. This is a problem because
currently selectors are the only way to propagate parameters from one HTL
script to another script/servlet (compare with SLING-7515).
The method {{createDispatcherOptions}} generates from a Map a String where the
entries are separated by {{,}}, i.e. comma. If either the map key or the map
value contain a comma itself the tokenization in
https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
works incorrectly!
Therefore instead of using the constructor with strings (with very
simple/incorrect parsing) you should rather call put for each option separately.
was:
Due to the way how the request dispatcher options are serialized into one big
string in
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
you cannot use e.g. selectors which contain a comma. This is a problem because
currently selectors are the only way to propagate parameters from one HTL
script to another script/servlet (compare with SLING-7515).
The method {{createDispatcherOptions}} generates from a Map a String where each
entry is separated by {{,}}. If either the map key or the map value contain a
comma itself the tokenization in
https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
works incorrectly!
Therefore instead of using the constructor with strings (with very
simple/incorrect parsing) you should rather call put for each option separately.
> ResourceRuntimeExtension: Modified selectors are always stripped after a
> comma.
> ---
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates from a Map a String where
> the entries are separated by {{,}}, i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with strings (with very
> simple/incorrect parsing) you should rather call put for each option
> separately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7516) ResourceRuntimeExtension: Selectors containing a comma are not treated correctly
[
https://issues.apache.org/jira/browse/SLING-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7516:
---
Summary: ResourceRuntimeExtension: Selectors containing a comma are not
treated correctly (was: ResourceRuntimeExtension: Selectors containing a comma
are not treated correctly.)
> ResourceRuntimeExtension: Selectors containing a comma are not treated
> correctly
>
>
> Key: SLING-7516
> URL: https://issues.apache.org/jira/browse/SLING-7516
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Due to the way how the request dispatcher options are serialized into one big
> string in
> https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
> you cannot use e.g. selectors which contain a comma. This is a problem
> because currently selectors are the only way to propagate parameters from one
> HTL script to another script/servlet (compare with SLING-7515).
> The method {{createDispatcherOptions}} generates from a Map a String where
> the entries are separated by {{,}}, i.e. comma. If either the map key or the
> map value contain a comma itself the tokenization in
> https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
> works incorrectly!
> Therefore instead of using the constructor with strings (with very
> simple/incorrect parsing) you should rather call put for each option
> separately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-7516) ResourceRuntimeExtension: Modified selectors are always stripped after a comma.
Konrad Windszus created SLING-7516:
--
Summary: ResourceRuntimeExtension: Modified selectors are always
stripped after a comma.
Key: SLING-7516
URL: https://issues.apache.org/jira/browse/SLING-7516
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
Reporter: Konrad Windszus
Due to the way how the request dispatcher options are serialized into one big
string in
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/cd7d67e66f624c66fe88dd208c4d2b8f7e85c8ec/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L214
you cannot use e.g. selectors which contain a comma. This is a problem because
currently selectors are the only way to propagate parameters from one HTL
script to another script/servlet (compare with SLING-7515).
The method {{createDispatcherOptions}} generates from a Map a String where each
entry is separated by {{,}}. If either the map key or the map value contain a
comma itself the tokenization in
https://github.com/apache/sling-org-apache-sling-api/blob/ec3dcf291b26e833b07a1f9c485bbe713a7ad4d5/src/main/java/org/apache/sling/api/request/RequestDispatcherOptions.java#L100
works incorrectly!
Therefore instead of using the constructor with strings (with very
simple/incorrect parsing) you should rather call put for each option separately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout
[ https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377186#comment-16377186 ] ASF GitHub Bot commented on SLING-7169: --- volteanu commented on issue #7: SLING-7169 URL: https://github.com/apache/sling-org-apache-sling-testing-clients/pull/7#issuecomment-368576193 should be merged after #5 and #6 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > FullTextIndexingTest sometimes fails with a timeout > --- > > Key: SLING-7169 > URL: https://issues.apache.org/jira/browse/SLING-7169 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Robert Munteanu >Priority: Major > Labels: sling-IT > Attachments: SLING-7169-logs.tar.gz > > > The test fails maybe 1 in 10 runs. I could reproduce this locally by running > many times. I've also seen it once on Jenkins. > **Old description below** > After upgrading the launchpad to commons.threads 3.2.10 the > FullTextIndexingTest failed ( [build > 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ). > I also reproduced it once locally. > [~kwin] - since the commons.threads release is the potential root cause, can > you please take a look at the failure and see if it's related? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout
[ https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377185#comment-16377185 ] ASF GitHub Bot commented on SLING-7169: --- volteanu opened a new pull request #7: SLING-7169 URL: https://github.com/apache/sling-org-apache-sling-testing-clients/pull/7 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > FullTextIndexingTest sometimes fails with a timeout > --- > > Key: SLING-7169 > URL: https://issues.apache.org/jira/browse/SLING-7169 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Robert Munteanu >Priority: Major > Labels: sling-IT > Attachments: SLING-7169-logs.tar.gz > > > The test fails maybe 1 in 10 runs. I could reproduce this locally by running > many times. I've also seen it once on Jenkins. > **Old description below** > After upgrading the launchpad to commons.threads 3.2.10 the > FullTextIndexingTest failed ( [build > 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ). > I also reproduced it once locally. > [~kwin] - since the commons.threads release is the potential root cause, can > you please take a look at the failure and see if it's related? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7515) ResourceRuntimeExtension: Allow to pass arbitrary options a request attributes via data-sly-resource
Konrad Windszus created SLING-7515:
--
Summary: ResourceRuntimeExtension: Allow to pass arbitrary options
a request attributes via data-sly-resource
Key: SLING-7515
URL: https://issues.apache.org/jira/browse/SLING-7515
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting HTL Engine 1.0.48-1.3.1
Reporter: Konrad Windszus
Currently it is only possible to pass parameters to another script/servlet when
using {{data-sly-resource}} with the options to modify the selector
(https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java).
It would be good if either all unknown options or only those with a specific
prefix would be passed as request attributes to the other script/servlet.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout
[ https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376994#comment-16376994 ] Robert Munteanu commented on SLING-7169: Also you could wait for Sling to adopt 1.8 - there is nothing blocking from doing that except we need someone to do the work :-) > FullTextIndexingTest sometimes fails with a timeout > --- > > Key: SLING-7169 > URL: https://issues.apache.org/jira/browse/SLING-7169 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Robert Munteanu >Priority: Major > Labels: sling-IT > Attachments: SLING-7169-logs.tar.gz > > > The test fails maybe 1 in 10 runs. I could reproduce this locally by running > many times. I've also seen it once on Jenkins. > **Old description below** > After upgrading the launchpad to commons.threads 3.2.10 the > FullTextIndexingTest failed ( [build > 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ). > I also reproduced it once locally. > [~kwin] - since the commons.threads release is the potential root cause, can > you please take a look at the failure and see if it's related? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout
[
https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376956#comment-16376956
]
Valentin Olteanu commented on SLING-7169:
-
[~tmueller], I've just encountered a problem: sling launchpad is still using
Oak 1.6, which doesn't support {{option(index tag ...)}}. Could we adapt the
index definitions and queries to not use that option, but be specific enough to
guarantee they are always selected?
> FullTextIndexingTest sometimes fails with a timeout
> ---
>
> Key: SLING-7169
> URL: https://issues.apache.org/jira/browse/SLING-7169
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
>Reporter: Robert Munteanu
>Priority: Major
> Labels: sling-IT
> Attachments: SLING-7169-logs.tar.gz
>
>
> The test fails maybe 1 in 10 runs. I could reproduce this locally by running
> many times. I've also seen it once on Jenkins.
> **Old description below**
> After upgrading the launchpad to commons.threads 3.2.10 the
> FullTextIndexingTest failed ( [build
> 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ).
> I also reproduced it once locally.
> [~kwin] - since the commons.threads release is the potential root cause, can
> you please take a look at the failure and see if it's related?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [Maven] Updating to parent pom 33 breaks all projects
True, that's why we intentionally keep the list short. Things like the servlet api or the logging api or JCR rarely need a change at all. For the OSGi dependencies we have this with every major release, so every 2 to 3 years, not a big deal either. Similar is true for Java version the project is using. We have the default in the parent pom. I guess we can continue to argue in one way or the other for some time. But I think there are no big wins with going one way or the other. Every approach has advantages and consequences. So let's stick with what we have now and only adjust if there is a real problem. My problem of updating to parent 33 is at least fixed now, after manually adding the missing dependencies to 10 projects. Thanks Carsten Konrad Windszus wrote > This is true for every other managed dependency in parent as well. > We do maintain a certain baseline with parent and I think this is good. > > Projects deliberately supporting older versions of the baseline cannot > upgrade to the most recent parent then! > >> On 26. Feb 2018, at 14:01, Carsten Ziegeler wrote: >> >> Sure works, but I guess it's better (yes arguing against myself now...) >> if each project references it's own version of those annotations :) >> Using a new version of the annotations and rebuilding your project will >> most likely bind your project to the latest DS version although you >> might not be using any feature of it. bnd uses the annotations package >> version to create the namespace for the XML (as far as I know). >> >> Updating a parent pom should not bring such surprises, so therefore not >> having these things in the pom at all is probably the best option. >> >> Carsten >> >> >> Oliver Lietz wrote >>> On Monday 26 February 2018 13:28:27 Carsten Ziegeler wrote: Yepp and following your argumentation then every project which starts to use R7 annotations can do so in its own pom. >>> >>> I guess we release a new parent with new version for annotations and >>> upgrading >>> to that parent should be enough – or do you expect new Maven coordinates >>> (again)? >>> >>> Regards, >>> O. >>> Let's leave it the way it is. It would just have been nice to hear about these breaking changes in some way. But I guess I could have seen this coming by watching the commits. So all fine Carsten Oliver Lietz wrote > On Monday 26 February 2018 13:05:46 Carsten Ziegeler wrote: >> Well, it seems I'm the only one complaining anyway... >> >> TBH, I don't see a real advantage in having these things in the >> dependency management at all then. But I guess, it will just be me >> again... > > I expect to see an update at least for versioning annotations with R7, no? > > O. > >> Carsten >> >> >> Oliver Lietz wrote >> >>> On Monday 26 February 2018 12:44:53 Carsten Ziegeler wrote: Well, how many non OSGi modules do we have? I totally agree that it's better to not declare dependencies in the parent pom. But every rule has an exception, and I think the annotations (not the api) are an exception. >>> >>> The Maven and bnd plugins, Maven archetypes, the IDE modules and several >>> testing modules are non-OSGi – but I don't have any numbers. >>> Upgrading to the new parent pom is now really a pain. >>> >>> I don't think adding one or two dependencies is a big deal (correctness >>> vs >>> convenience) and we have already updated several modules to Parent 33. >>> If others disagree we can add back those annotations with Parent 34. >>> >>> Regards, >>> O. >>> Regards Carsten Oliver Lietz wrote > On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote: >> Hi > > Hi Carsten, > >> it seems that updating to parent pom 33 is way harder than it should >> be. >> For an unknown reason the OSGi annotations are no longer declared as >> dependencies, requiring now each and every project to define >> them...which I think is really annoying. >> >> The change in question is referencing SLING-7384, but I can't find a >> discussion nor reason in there. So why has this been done? > > in my opinion dependencies should only be managed in parent and not > declared. We have several modules which are "not OSGi" and they > inherit > those dependencies although not used at all. > > Regards, > O. > >> Regards >> Carsten >>> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
This is true for every other managed dependency in parent as well. We do maintain a certain baseline with parent and I think this is good. Projects deliberately supporting older versions of the baseline cannot upgrade to the most recent parent then! > On 26. Feb 2018, at 14:01, Carsten Ziegeler wrote: > > Sure works, but I guess it's better (yes arguing against myself now...) > if each project references it's own version of those annotations :) > Using a new version of the annotations and rebuilding your project will > most likely bind your project to the latest DS version although you > might not be using any feature of it. bnd uses the annotations package > version to create the namespace for the XML (as far as I know). > > Updating a parent pom should not bring such surprises, so therefore not > having these things in the pom at all is probably the best option. > > Carsten > > > Oliver Lietz wrote >> On Monday 26 February 2018 13:28:27 Carsten Ziegeler wrote: >>> Yepp and following your argumentation then every project which starts to >>> use R7 annotations can do so in its own pom. >> >> I guess we release a new parent with new version for annotations and >> upgrading >> to that parent should be enough – or do you expect new Maven coordinates >> (again)? >> >> Regards, >> O. >> >>> Let's leave it the way it is. It would just have been nice to hear about >>> these breaking changes in some way. But I guess I could have seen this >>> coming by watching the commits. So all fine >>> >>> Carsten >>> >>> >>> Oliver Lietz wrote >>> On Monday 26 February 2018 13:05:46 Carsten Ziegeler wrote: > Well, it seems I'm the only one complaining anyway... > > TBH, I don't see a real advantage in having these things in the > dependency management at all then. But I guess, it will just be me > again... I expect to see an update at least for versioning annotations with R7, no? O. > Carsten > > > Oliver Lietz wrote > >> On Monday 26 February 2018 12:44:53 Carsten Ziegeler wrote: >>> Well, how many non OSGi modules do we have? I totally agree that it's >>> better to not declare dependencies in the parent pom. But every rule >>> has >>> an exception, and I think the annotations (not the api) are an >>> exception. >> >> The Maven and bnd plugins, Maven archetypes, the IDE modules and several >> testing modules are non-OSGi – but I don't have any numbers. >> >>> Upgrading to the new parent pom is now really a pain. >> >> I don't think adding one or two dependencies is a big deal (correctness >> vs >> convenience) and we have already updated several modules to Parent 33. >> If others disagree we can add back those annotations with Parent 34. >> >> Regards, >> O. >> >>> Regards >>> Carsten >>> >>> Oliver Lietz wrote >>> On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote: > Hi Hi Carsten, > it seems that updating to parent pom 33 is way harder than it should > be. > For an unknown reason the OSGi annotations are no longer declared as > dependencies, requiring now each and every project to define > them...which I think is really annoying. > > The change in question is referencing SLING-7384, but I can't find a > discussion nor reason in there. So why has this been done? in my opinion dependencies should only be managed in parent and not declared. We have several modules which are "not OSGi" and they inherit those dependencies although not used at all. Regards, O. > Regards > Carsten >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
On Monday 26 February 2018 13:52:56 Carsten Ziegeler wrote: > Again, I totally agree for *normal* dependencies and again, I'm not > talking about those. I'm talking about the annotations only - which are > separate artifacts anyway. I see your point. O. > Carsten > > > Oliver Lietz wrote > > > On Monday 26 February 2018 12:51:14 Konrad Windszus wrote: > >> @Carsten: > >> Which dependency exactly to you want to declare now? The aggregate one > >> for > >> annotations or the individual ones per annotation definition? > >> > >> But I rather tend to agree with Oli here. We should really force every > >> project to declare all(!) its dependencies. Having a dirty classpath for > >> non-OSGi modules just because you derive from parent does not seem right > >> to > >> me. This should be a one time effort (given that OSGi does not rename the > >> artifacts again in the future). > > > > And here is the example for dirty classpath: > > > > https://github.com/apache/sling-org-apache-sling-jcr-contentloader/blob/ma > > ster/pom.xml#L113 > > > > This is *NOT* a problem of Pax Exam. > > > > Regards, > > O. > > > >> Konrad > >> > >>> On 26. Feb 2018, at 12:44, Carsten Ziegeler > >>> wrote: > >>> > >>> Well, how many non OSGi modules do we have? I totally agree that it's > >>> better to not declare dependencies in the parent pom. But every rule has > >>> an exception, and I think the annotations (not the api) are an > >>> exception. > >>> > >>> Upgrading to the new parent pom is now really a pain. > >>> > >>> Regards > >>> Carsten > >>> > >>> Oliver Lietz wrote > >>> > On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote: > > Hi > > Hi Carsten, > > > it seems that updating to parent pom 33 is way harder than it should > > be. > > For an unknown reason the OSGi annotations are no longer declared as > > dependencies, requiring now each and every project to define > > them...which I think is really annoying. > > > > The change in question is referencing SLING-7384, but I can't find a > > discussion nor reason in there. So why has this been done? > > in my opinion dependencies should only be managed in parent and not > declared. We have several modules which are "not OSGi" and they inherit > those dependencies although not used at all. > > Regards, > O. > > > Regards > > Carsten
