[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15292010#comment-15292010
]
Justin Edelson commented on SLING-5739:
---
There's one minor issue in the patch - the ChildResourceViaProvider is not in
the correct package. I'll correct this when merging.
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15291574#comment-15291574
]
Justin Edelson commented on SLING-5739:
---
also includes a new @Via provider, ChildResource as shown above.
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15291569#comment-15291569
]
Justin Edelson commented on SLING-5739:
---
proposed patch: https://codereview.appspot.com/298180043
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5739) [Sling Models] Allow for extensible @Via providers
Justin Edelson created SLING-5739:
-
Summary: [Sling Models] Allow for extensible @Via providers
Key: SLING-5739
URL: https://issues.apache.org/jira/browse/SLING-5739
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Justin Edelson
Currently, @Via support in Sling Models is limited to JavaBean properties. It
would be useful to be able to extend this and allow for downstream projects to
add new @Via providers.
Proposing to support this by extending the @Via annotation
{code}
@Via(value = "jcr:content", type = ChildResource.class)
{code}
The default type is BeanProperty (the current behavior).
New providers can be added by implementing a ViaProvider SPI and provide a
marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5682) special json array import for sling post servlet to post orderered structures
[
https://issues.apache.org/jira/browse/SLING-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-5682:
---
Attachment: SLING-5682.patch
Hi [~bdelacretaz], you'll find a patch for this
i created the "ordered-json" extension for that matter. Was forced to modify a
bit the JSON reader so OrderedJsonReader (and its tests) reuses most of it.
> special json array import for sling post servlet to post orderered structures
> -
>
> Key: SLING-5682
> URL: https://issues.apache.org/jira/browse/SLING-5682
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Nicolas Peltier
> Attachments: SLING-5682.patch
>
>
> it is not possible right now to post an ordered structure through json data
> [0]. this ticket is for implementing [~bdelacretaz] proposal to use JSON
> Arrays:
> {noformat}
> {
>"title": "The parent node",
>"SLING:ordered": [{
>"SLING:name": "first",
>"title": "This comes first"
>}, {
>"SLING:name": "second",
>"title": "This comes second"
>}]
> }
> {noformat}
> This needs to be triggered by selector or content-type switch so that
> the existing POST behavior is unchanged.
> I suppose having SLING:ordered should then also set the appropriate
> mixin on the parent node.
> [0] http://sling.markmail.org/thread/plov2u7kibscn7sx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5738) Add support for configuring a pattern for the model files to be read
[ https://issues.apache.org/jira/browse/SLING-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-5738. - Resolution: Fixed Added new modelPattern configuration > Add support for configuring a pattern for the model files to be read > > > Key: SLING-5738 > URL: https://issues.apache.org/jira/browse/SLING-5738 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Slingstart Maven Plugin 1.4.4 > > > Right now, the plugin reads all files ending with .txt or .model from the > configured directory. We should make the regexp for this configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5738) Add support for configuring a pattern for the model files to be read
Carsten Ziegeler created SLING-5738: --- Summary: Add support for configuring a pattern for the model files to be read Key: SLING-5738 URL: https://issues.apache.org/jira/browse/SLING-5738 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.4.4 Right now, the plugin reads all files ending with .txt or .model from the configured directory. We should make the regexp for this configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5666) Unscheduling a job should remove corresponding node
[
https://issues.apache.org/jira/browse/SLING-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290990#comment-15290990
]
Damien Obrist commented on SLING-5666:
--
[~cziegeler] Thanks! The fix works and looks good to me from what I can see.
One thing I wonder about though is that {{ScheduledJobHandler#remove}} contains
the following
[code|https://github.com/apache/sling/blob/caba56abb49cb173cf6c9903a0facb2b6d31e56c/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java#L480-L485]:
{code}
synchronized ( this.scheduledJobs ) {
final Holder h = scheduledJobs.remove(scheduleKey);
if ( h != null && h.info != null ) {
jobScheduler.unscheduleJob(h.info);
}
}
{code}
This code should in theory already call {{JobSchedulerImpl#unscheduleJob}},
which you now call explicitly in your [updated
fix|https://fisheye6.atlassian.com/changelog/sling?cs=1744360]. Except that
this doesn't seem to happen, because the map
{{ScheduledJobHandler.scheduledJobs}} doesn't contain the job yet - it is added
there only asynchronously in {{ScheduledJobHandler#handleAddUpdate}}. Is that
maybe something that should change? I don't grasp the complete code, so I can't
really tell.
> Unscheduling a job should remove corresponding node
> ---
>
> Key: SLING-5666
> URL: https://issues.apache.org/jira/browse/SLING-5666
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Event 4.0.0, Event 4.0.2
>Reporter: Damien Obrist
>Assignee: Carsten Ziegeler
> Fix For: Event 4.1.0
>
>
> Unscheduling a previously scheduled job does not remove the corresponding
> node below {{/var/eventing/scheduled-jobs}}:
> {code:java}
> ScheduledJobInfo info =
> jobManager.createJob(topic).schedule().at(date).add();
> // creates /var/eventing/scheduled-jobs/c204a1ad-b161-4e76-9dfe-4152bca088cf
> info.unschedule();
> // /var/eventing/scheduled-jobs/c204a1ad-b161-4e76-9dfe-4152bca088cf persists
> {code}
> This can lead to the situation where
> [ScheduledJobHandler#scan|https://github.com/apache/sling/blob/caba56abb49cb173cf6c9903a0facb2b6d31e56c/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java#L142-L174]
> picks the node back up again and reschedules the job.
> This is a regression introduced by SLING-4680. Before the changes of
> SLING-4680, {{JobSchedulerImpl#unschedule}} took care of [removing the
> node|https://github.com/apache/sling/blob/6eaa6a131b4013c5b4990ee126f6af1c5710d5de/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/JobSchedulerImpl.java#L335-L353].
> Currently, this is [not being done
> anymore|https://github.com/apache/sling/blob/caba56abb49cb173cf6c9903a0facb2b6d31e56c/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/scheduling/JobSchedulerImpl.java#L196-L202].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected
[
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-5712.
Resolution: Fixed
Ok, thanks! Marking this resolved.
> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
> Attachments: SanitizeResourceNameTest.patch,
> TEST-org.apache.sling.repoinit.it.RepoInitIT.xml,
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml,
> TEST-org.apache.sling.testing.teleporter.client.SanitizeResourceNameTest.xml,
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing
> tests on Teleporter module .
> See attachment
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests
> code like
> {code:java}
> assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of
> {code:java}
> assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This was a good fix for the failing tests under Teleporter module but
> unfortunately this fix causes RepoInitIT integration test failure because the
> resource name returned by Teleporter ClassResourceVisitor used to create test
> bundles inside ClientSideTeleporter#buildTestBundle must use '/' style
> slashes, not '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name
> like "\name" will create a jar containing a folder with an empty name
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml"
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends
> also by what is expected to have in resourcePath parameter of method
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/"
> regardless of operating system.
> See "windows.patch"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected
[
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290915#comment-15290915
]
Emanuele Lombardi commented on SLING-5712:
--
Double checked, everything is ok.
Thanks
> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
> Attachments: SanitizeResourceNameTest.patch,
> TEST-org.apache.sling.repoinit.it.RepoInitIT.xml,
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml,
> TEST-org.apache.sling.testing.teleporter.client.SanitizeResourceNameTest.xml,
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing
> tests on Teleporter module .
> See attachment
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests
> code like
> {code:java}
> assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of
> {code:java}
> assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This was a good fix for the failing tests under Teleporter module but
> unfortunately this fix causes RepoInitIT integration test failure because the
> resource name returned by Teleporter ClassResourceVisitor used to create test
> bundles inside ClientSideTeleporter#buildTestBundle must use '/' style
> slashes, not '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name
> like "\name" will create a jar containing a folder with an empty name
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml"
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends
> also by what is expected to have in resourcePath parameter of method
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/"
> regardless of operating system.
> See "windows.patch"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5737) Add light checkpointing mechanism to in-memory queues
Tommaso Teofili created SLING-5737: -- Summary: Add light checkpointing mechanism to in-memory queues Key: SLING-5737 URL: https://issues.apache.org/jira/browse/SLING-5737 Project: Sling Issue Type: Improvement Components: Distribution Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution 0.2.0 An advantage in using In-memory queues is that they avoid writing (e.g. to the repository) intensively, however it'd be good if we could implement a light checkpointing mechanism that allows instances that crashed to be able to recover at least some of the items when they are restarted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5736) Add hintName to ContentSerializer factories in extensions
[ https://issues.apache.org/jira/browse/SLING-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-5736. Resolution: Fixed Assignee: Tommaso Teofili Fix Version/s: Content Distribution Extensions 0.1.0 fixed in r1744533 > Add hintName to ContentSerializer factories in extensions > - > > Key: SLING-5736 > URL: https://issues.apache.org/jira/browse/SLING-5736 > Project: Sling > Issue Type: Improvement > Components: Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Extensions 0.1.0 > > > For better usability in WebConsole, ContentSerializer factories should have > the _webconsole.configurationFactory.nameHint_ property set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5736) Add hintName to ContentSerializer factories in extensions
[ https://issues.apache.org/jira/browse/SLING-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-5736: --- Description: For better usability in WebConsole, ContentSerializer factories should have the _webconsole.configurationFactory.nameHint_ property set. > Add hintName to ContentSerializer factories in extensions > - > > Key: SLING-5736 > URL: https://issues.apache.org/jira/browse/SLING-5736 > Project: Sling > Issue Type: Improvement > Components: Distribution >Reporter: Tommaso Teofili > > For better usability in WebConsole, ContentSerializer factories should have > the _webconsole.configurationFactory.nameHint_ property set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5736) Add hintName to ContentSerializer factories in extensions
[ https://issues.apache.org/jira/browse/SLING-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-5736: --- Summary: Add hintName to ContentSerializer factories in extensions (was: Add hintName to ContentSerializers in extensions) > Add hintName to ContentSerializer factories in extensions > - > > Key: SLING-5736 > URL: https://issues.apache.org/jira/browse/SLING-5736 > Project: Sling > Issue Type: Improvement > Components: Distribution >Reporter: Tommaso Teofili > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5736) Add hintName to ContentSerializers in extensions
Tommaso Teofili created SLING-5736: -- Summary: Add hintName to ContentSerializers in extensions Key: SLING-5736 URL: https://issues.apache.org/jira/browse/SLING-5736 Project: Sling Issue Type: Improvement Components: Distribution Reporter: Tommaso Teofili -- This message was sent by Atlassian JIRA (v6.3.4#6332)
