[jira] [Resolved] (SLING-7974) CMS - Core - Can't Send Email
[ https://issues.apache.org/jira/browse/SLING-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-7974. - Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-app-cms/commit/4b689c9c382827802509f04bb5117d1e6d497c8f > CMS - Core - Can't Send Email > - > > Key: SLING-7974 > URL: https://issues.apache.org/jira/browse/SLING-7974 > Project: Sling > Issue Type: Bug >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: App CMS 0.10.2 > > > Previously I was able to use Commons Email to send emails via Apache Sling, > but after updating to new JRE support, I'm running into the following > exception when attempting to send emails: > org.apache.commons.mail.EmailException: Sending the email to the following > server failed : [smtp.sendgrid.net:2525|http://smtp.sendgrid.net:2525/] at > org.apache.commons.mail.Email.sendMimeMessage(Email.java:1469) > [org.apache.commons.email:1.5.0] at > org.apache.commons.mail.Email.send(Email.java:1496) > [org.apache.commons.email:1.5.0] at > org.adobecommunity.site.impl.jobs.EmailQueueConsumer.process(EmailQueueConsumer.java:113) > [org.adobecommunity.site:1.0.0.SNAPSHOT] at > org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502) > [org.apache.sling.event:4.2.12] at > org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293) > [org.apache.sling.event:4.2.12] at > org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60) > [org.apache.sling.event:4.2.12] at > org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229) > [org.apache.sling.event:4.2.12] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) Caused by: > javax.mail.MessagingException: IOException while sending message at > com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1167) > [javax.mail:1.5.0.b01] at javax.mail.Transport.send0(Transport.java:254) > [javax.mail:1.5.0.b01] at javax.mail.Transport.send(Transport.java:124) > [javax.mail:1.5.0.b01] at > org.apache.commons.mail.Email.sendMimeMessage(Email.java:1459) > [org.apache.commons.email:1.5.0] ... 9 common frames omitted Caused by: > javax.activation.UnsupportedDataTypeException: text/plain; charset=us-ascii > at javax.activation.DataHandler.writeTo(DataHandler.java:78) > [org.apache.geronimo.specs.geronimo-activation_1.1_spec:1.1.0] at > javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1574) > [javax.mail:1.5.0.b01] at > javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1840) > [javax.mail:1.5.0.b01] at > com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1119) > [javax.mail:1.5.0.b01] ... 12 common frames omitted > > This is due to including the Geronimo Specs Activation as indicated by > [~karlpauls] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7974) CMS - Core - Can't Send Email
Dan Klco created SLING-7974: --- Summary: CMS - Core - Can't Send Email Key: SLING-7974 URL: https://issues.apache.org/jira/browse/SLING-7974 Project: Sling Issue Type: Bug Affects Versions: App CMS 0.10.0 Reporter: Dan Klco Assignee: Dan Klco Fix For: App CMS 0.10.2 Previously I was able to use Commons Email to send emails via Apache Sling, but after updating to new JRE support, I'm running into the following exception when attempting to send emails: org.apache.commons.mail.EmailException: Sending the email to the following server failed : [smtp.sendgrid.net:2525|http://smtp.sendgrid.net:2525/] at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1469) [org.apache.commons.email:1.5.0] at org.apache.commons.mail.Email.send(Email.java:1496) [org.apache.commons.email:1.5.0] at org.adobecommunity.site.impl.jobs.EmailQueueConsumer.process(EmailQueueConsumer.java:113) [org.adobecommunity.site:1.0.0.SNAPSHOT] at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502) [org.apache.sling.event:4.2.12] at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293) [org.apache.sling.event:4.2.12] at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60) [org.apache.sling.event:4.2.12] at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229) [org.apache.sling.event:4.2.12] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: javax.mail.MessagingException: IOException while sending message at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1167) [javax.mail:1.5.0.b01] at javax.mail.Transport.send0(Transport.java:254) [javax.mail:1.5.0.b01] at javax.mail.Transport.send(Transport.java:124) [javax.mail:1.5.0.b01] at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1459) [org.apache.commons.email:1.5.0] ... 9 common frames omitted Caused by: javax.activation.UnsupportedDataTypeException: text/plain; charset=us-ascii at javax.activation.DataHandler.writeTo(DataHandler.java:78) [org.apache.geronimo.specs.geronimo-activation_1.1_spec:1.1.0] at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1574) [javax.mail:1.5.0.b01] at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1840) [javax.mail:1.5.0.b01] at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1119) [javax.mail:1.5.0.b01] ... 12 common frames omitted This is due to including the Geronimo Specs Activation as indicated by [~karlpauls] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7967) CMS - UI - Search Does not Update Path in Component Editor
[ https://issues.apache.org/jira/browse/SLING-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-7967. - Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-app-cms/commit/2fce173c67b55ff8adf21d55012bcaec35592a66 > CMS - UI - Search Does not Update Path in Component Editor > -- > > Key: SLING-7967 > URL: https://issues.apache.org/jira/browse/SLING-7967 > Project: Sling > Issue Type: Bug >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: App CMS 0.10.2 > > > Currently, when you edit a component and use the path finder to find a link > the select button does not update the field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7971) CMS - UI - Whole Dialog Add Template Draggable
[ https://issues.apache.org/jira/browse/SLING-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-7971. - Resolution: Fixed > CMS - UI - Whole Dialog Add Template Draggable > --- > > Key: SLING-7971 > URL: https://issues.apache.org/jira/browse/SLING-7971 > Project: Sling > Issue Type: Bug >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Minor > Fix For: App CMS 0.10.2 > > > The whole Add Template dialog is draggable, including fields, etc. This is > different than other dialogs where only the header is draggable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7973) CMS - UI -Remove Editor JS Dependency on JQuery
[ https://issues.apache.org/jira/browse/SLING-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-7973. - Resolution: Fixed > CMS - UI -Remove Editor JS Dependency on JQuery > --- > > Key: SLING-7973 > URL: https://issues.apache.org/jira/browse/SLING-7973 > Project: Sling > Issue Type: Improvement >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Trivial > Fix For: App CMS 0.10.2 > > > Currently the editor depends on JQuery which is not necessary for what we're > doing and introduces unnecessary complexity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7971) CMS - UI - Whole Dialog Add Template Draggable
[ https://issues.apache.org/jira/browse/SLING-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636076#comment-16636076 ] Dan Klco commented on SLING-7971: - Fixed in https://github.com/apache/sling-org-apache-sling-app-cms/commit/c0b341bff51253cfb59ed2e8902c0cbce13f98ca > CMS - UI - Whole Dialog Add Template Draggable > --- > > Key: SLING-7971 > URL: https://issues.apache.org/jira/browse/SLING-7971 > Project: Sling > Issue Type: Bug >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Minor > Fix For: App CMS 0.10.2 > > > The whole Add Template dialog is draggable, including fields, etc. This is > different than other dialogs where only the header is draggable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7973) CMS - UI -Remove Editor JS Dependency on JQuery
[ https://issues.apache.org/jira/browse/SLING-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636074#comment-16636074 ] Dan Klco commented on SLING-7973: - Fixed in https://github.com/apache/sling-org-apache-sling-app-cms/commit/c0b341bff51253cfb59ed2e8902c0cbce13f98ca > CMS - UI -Remove Editor JS Dependency on JQuery > --- > > Key: SLING-7973 > URL: https://issues.apache.org/jira/browse/SLING-7973 > Project: Sling > Issue Type: Improvement >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Trivial > Fix For: App CMS 0.10.2 > > > Currently the editor depends on JQuery which is not necessary for what we're > doing and introduces unnecessary complexity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7972) CMS - UI - Template Edit / Move / Delete Title Missing
[ https://issues.apache.org/jira/browse/SLING-7972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-7972. - Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-app-cms/commit/c0b341bff51253cfb59ed2e8902c0cbce13f98ca > CMS - UI - Template Edit / Move / Delete Title Missing > -- > > Key: SLING-7972 > URL: https://issues.apache.org/jira/browse/SLING-7972 > Project: Sling > Issue Type: Bug >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Trivial > Fix For: App CMS 0.10.2 > > > When editing / moving or deleting a template, the modal title is blank. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7973) Remove Editor JS Dependency on JQuery
Dan Klco created SLING-7973: --- Summary: Remove Editor JS Dependency on JQuery Key: SLING-7973 URL: https://issues.apache.org/jira/browse/SLING-7973 Project: Sling Issue Type: Improvement Affects Versions: App CMS 0.10.0 Reporter: Dan Klco Assignee: Dan Klco Fix For: App CMS 0.10.2 Currently the editor depends on JQuery which is not necessary for what we're doing and introduces unnecessary complexity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7973) CMS - UI -Remove Editor JS Dependency on JQuery
[ https://issues.apache.org/jira/browse/SLING-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco updated SLING-7973: Summary: CMS - UI -Remove Editor JS Dependency on JQuery (was: Remove Editor JS Dependency on JQuery) > CMS - UI -Remove Editor JS Dependency on JQuery > --- > > Key: SLING-7973 > URL: https://issues.apache.org/jira/browse/SLING-7973 > Project: Sling > Issue Type: Improvement >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Trivial > Fix For: App CMS 0.10.2 > > > Currently the editor depends on JQuery which is not necessary for what we're > doing and introduces unnecessary complexity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7972) CMS - UI - Template Edit / Move / Delete Title Missing
Dan Klco created SLING-7972: --- Summary: CMS - UI - Template Edit / Move / Delete Title Missing Key: SLING-7972 URL: https://issues.apache.org/jira/browse/SLING-7972 Project: Sling Issue Type: Bug Affects Versions: App CMS 0.10.0 Reporter: Dan Klco Assignee: Dan Klco Fix For: App CMS 0.10.2 When editing / moving or deleting a template, the modal title is blank. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7971) CMS - UI - Whole Dialog Add Template Draggable
Dan Klco created SLING-7971: --- Summary: CMS - UI - Whole Dialog Add Template Draggable Key: SLING-7971 URL: https://issues.apache.org/jira/browse/SLING-7971 Project: Sling Issue Type: Bug Affects Versions: App CMS 0.10.0 Reporter: Dan Klco Assignee: Dan Klco Fix For: App CMS 0.10.2 The whole Add Template dialog is draggable, including fields, etc. This is different than other dialogs where only the header is draggable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi Jason, thanks for your feedback! On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey wrote: > ...To restate. Given a resource, you should be able to define what properties > that resource can contain and what child resources it can be the parent of... Yes, among other things including some that we might discover along the way. > ...1. There's some things that are implicit. For example, stating that a > resource can be a parent of a resource would imply > that you could perform the action to create the child resource Absolutely, which means we can generate hyperlinks for such operations automatically. >... We're still a REST platform, do we need to have actions that are different >then the standard REST methods? Would we have something different?... I think actions can be more specific, at least in terms of their link:rel values. A hyperlink can say link:rel=sling.create.imagefolder, method=POST, path=./images as basically it, along with the Sling Type System (STS) typedef, needs to contain enough information to generate an HTML form when generating a UI. maybe...just thinking outloud, but basically an action can have a more specific name than POST to clarify what it does exactly. > ...Looking at the code, I get confused between a type for a resource and a > sling:resourceType. I believe these are different things I think it's fair to describe the code as a hack created when those ideas where still emerging ;-) My point of view is that a resourceType points to an STS typedef, which conceptually points to rendering scripts or servlets. That's conceptually...in practice I think we can keep the current script resolution mechanism, but the STS typedef might validate operations before passing them on. Does that address your concerns? That's all still vague for now anyway, needs to be defined more clearly and proven with prototypes. -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
+1 for the idea. To restate. Given a resource, you should be able to define what properties that resource can contain and what child resources it can be the parent of. Feedback: 1. There's some things that are implicit. For example, stating that a resource can be a parent of a resource would imply that you could perform the action to create the child resource. 2. Terminology We're still a REST platform, do we need to have actions that are different then the standard REST methods? Would we have something different? Looking at the code, I get confused between a type for a resource and a sling:resourceType. I believe these are different things. The resourceType defines how the data is rendered and the resourceType can be overridden. Where as the type of a resource as we are talking about defines it structure, without regard to how it's rendered. I hope these are different things :) - Jason On Tue, Oct 2, 2018, at 7:59 AM, Bertrand Delacretaz wrote: > Hi, > > Recent discussions with a number of people from the Sling community > [1] have helped clarify my thoughts about this, I have started a wiki > page at > https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements > and feedback is welcome, on that page or here. > > Roughly, the goal is to create a Sling Type System that defines much > more precisely what the various Resource Types can contain, how they > work together, etc. with the goal of generating self-describing > interfaces. > > Let's see where this leads, it's just rough ideas so far but it feels > like a useful unifying concept for Sling. > > -Bertrand > > [1] along with reading "a conversation with Alan Kay, creator of > Smalltalk" - https://queue.acm.org/detail.cfm?id=1039523
Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, Recent discussions with a number of people from the Sling community [1] have helped clarify my thoughts about this, I have started a wiki page at https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements and feedback is welcome, on that page or here. Roughly, the goal is to create a Sling Type System that defines much more precisely what the various Resource Types can contain, how they work together, etc. with the goal of generating self-describing interfaces. Let's see where this leads, it's just rough ideas so far but it feels like a useful unifying concept for Sling. -Bertrand [1] along with reading "a conversation with Alan Kay, creator of Smalltalk" - https://queue.acm.org/detail.cfm?id=1039523
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635308#comment-16635308
]
Valentin Olteanu commented on SLING-7969:
-
I've checked again on a fresh instance and the Json Factory has a buffer of
exactly 21103224 bytes. This happens both with and without the patch. Probably,
over time, the buffer get doubled in size and doesn't shrink back.
Looking over on the internet, I've stumbled upon [this
discussion|http://tomee-openejb.979440.n4.nabble.com/JsonParserFactoryImpl-holds-20mb-heap-memory-when-used-as-jaxrs-client-in-tomee-td4678031.html],
where johnzon maintainers state that is by design. So I'm not sure how much
can be done in this case.
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-7970) Add Feature Model introspection service
David Bosschaert created SLING-7970: --- Summary: Add Feature Model introspection service Key: SLING-7970 URL: https://issues.apache.org/jira/browse/SLING-7970 Project: Sling Issue Type: New Feature Components: Feature Model Reporter: David Bosschaert Assignee: David Bosschaert We need a service that can report on the feature model that is launched by the launcher, for introspection purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
adaptTo() 2018 - Videos and Gallery online
The video recordings for all talks are now online: https://adapt.to/2018/schedule Visit our Youtube channel: https://www.youtube.com/c/adaptTo For further impressions check out our image gallery: https://adapt.to/2018/en/conference/gallery.html See you next year! Stefan
[jira] [Closed] (SLING-7859) The HTL engine sets the script bindings two times
[
https://issues.apache.org/jira/browse/SLING-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-7859.
---
> The HTL engine sets the script bindings two times
> -
>
> Key: SLING-7859
> URL: https://issues.apache.org/jira/browse/SLING-7859
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.26
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.0.56-1.4.0
>
>
> When calling
> {{org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine#eval}}
> the bindings from the script context will be set two times: once by the
> engine and once more by the resulting compiled script. Although it has no
> side-effect, executing the same operation twice is redundant. Only the
> compiled script should perform this operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7755) JavaUseProvider might attempt to instantiate interfaces or abstract classes
[ https://issues.apache.org/jira/browse/SLING-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-7755. --- > JavaUseProvider might attempt to instantiate interfaces or abstract classes > --- > > Key: SLING-7755 > URL: https://issues.apache.org/jira/browse/SLING-7755 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Santiago García Pimentel >Assignee: Radu Cotescu >Priority: Major > Fix For: Scripting HTL Engine 1.0.56-1.4.0, Scripting HTL Testing > Content 1.0.12-1.4.0, Scripting HTL Testing 1.0.12-1.4.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If you have a data-sly-use which receives a FQN of an interface or abstract > class, the Java Use provider will not make any checks and will try to > instantiate it anyway, causing a java.lang.NoSuchMethodException > com.example.InterfaceName.(). > This is a problem when your code base normally relies in an adapter factory > to get implementation of an interface and the adaptTo returns null, causing > sightly to try the java Use provider > The Java Use provider should not attempt to instantiate blindly classes that > it receives. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7915) Configure the package name under which HTL classes are generated
[
https://issues.apache.org/jira/browse/SLING-7915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-7915.
---
> Configure the package name under which HTL classes are generated
>
>
> Key: SLING-7915
> URL: https://issues.apache.org/jira/browse/SLING-7915
> Project: Sling
> Issue Type: New Feature
> Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Labels: adaptTo18
> Fix For: HTL Maven Plugin 1.2.0-1.4.0
>
>
> Starting with version 1.1.0 of the {{htl-maven-plugin}} the
> {{generateJavaClasses}} option allows to precompile the HTL scripts of a
> project. However, the plugin doesn't yet provide the option to select under
> which package the classes will be generated.
> On Sling instances this happens under the
> {{org.apache.sling.scripting.sightly}} package. Allowing the value to be
> configurable would facilitate the debugging of the generated Java classes, no
> matter how they will be deployed / generated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[RESULT][VOTE] Release Apache Sling HTL Maven Plugin 1.2.0-1.4.0
Hi, The release passes with 4 binding +1s from: Carsten Ziegeler, Andrei Dulvac, Radu Cotescu and Stefan Seifert. Thanks, Radu
[RESULT][VOTE] Release Apache Sling Scripting HTL Engine 1.0.56-1.4.0, Apache Sling Scripting HTL Testing Content 1.0.12-1.4.0, Apache Sling Scripting HTL Testing 1.0.12-1.4.0
Hi, The release passes with 3 binding +1s from: Robert Munteanu, Radu Cotescu and Stefan Seifert. Thanks, Radu
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635134#comment-16635134
]
Timothee Maret commented on SLING-7969:
---
[~volteanu] could you give it a shot in your test infrastructure ?
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635133#comment-16635133
]
Timothee Maret commented on SLING-7969:
---
https://github.com/tmaret/sling-org-apache-sling-discovery-commons/commit/edba8e9d8a5ec21f6a95945440e9c9825f00e666
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7968) FeatureModelConverter should use FeatureProvider instead of ArtifactManager
[ https://issues.apache.org/jira/browse/SLING-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-7968. --- Resolution: Fixed Assignee: Karl Pauls I merged the pull requests. [~bosschaert], we can talk about moving the ArtifactProviders around separately. > FeatureModelConverter should use FeatureProvider instead of ArtifactManager > --- > > Key: SLING-7968 > URL: https://issues.apache.org/jira/browse/SLING-7968 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.8.2, Feature Model Converter > 0.1.2 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Feature Model Converter 0.1.4, Slingstart Maven Plugin > 1.8.4 > > Time Spent: 20m > Remaining Estimate: 0h > > The feature model converter currently requires an ArtifactManager. This is > not needed and can be replaced with the less powerful FeatureProvider. > Subsequently, we can use the simpler interface to actually use the maven > resolver to resolve features in the Slingstart Maven Plugin (instead of using > a ArtifactManager when invoking the model convert. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7968) FeatureModelConverter should use FeatureProvider instead of ArtifactManager
[ https://issues.apache.org/jira/browse/SLING-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635130#comment-16635130 ] ASF GitHub Bot commented on SLING-7968: --- karlpauls closed pull request #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1 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 > FeatureModelConverter should use FeatureProvider instead of ArtifactManager > --- > > Key: SLING-7968 > URL: https://issues.apache.org/jira/browse/SLING-7968 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.8.2, Feature Model Converter > 0.1.2 >Reporter: Karl Pauls >Priority: Major > Fix For: Feature Model Converter 0.1.4, Slingstart Maven Plugin > 1.8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > The feature model converter currently requires an ArtifactManager. This is > not needed and can be replaced with the less powerful FeatureProvider. > Subsequently, we can use the simpler interface to actually use the maven > resolver to resolve features in the Slingstart Maven Plugin (instead of using > a ArtifactManager when invoking the model convert. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] karlpauls closed pull request #4: SLING-7968: Use FeatureProvider instead of ArtifactManager.
karlpauls closed pull request #4: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-slingstart-maven-plugin/pull/4 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
[GitHub] karlpauls closed pull request #1: SLING-7968: Use FeatureProvider instead of ArtifactManager.
karlpauls closed pull request #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1 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
Re: How to manage repoinit language + implementation evolutions?
+1 - didn't think of STRICT but yeah, that makes sense to me :-) regards, Karl On Tue, Oct 2, 2018 at 10:06 AM Bertrand Delacretaz wrote: > > Hi, > > On Tue, Oct 2, 2018 at 7:46 AM Karl Pauls wrote: > > Can’t we stay BC and just introduce a new command that has the new behavior > > and keep the old one as is?... > > Great idea, this is much simpler to implement and manage indeed, at > the cost of making the language slightly more complicated. > > I think having to differentiate between service and non-service users > when deleting is somewhat of an edge case, which a STRICT modifier can > address - so how about: > > DELETE STRICT USER -> delete user only if it's NOT a service user > DELETE STRICT SERVICE USER -> delete user only if it's a service user > DELETE USER -> delete both service and non-service user > DELETE SERVICE USER -> same but deprecated, indicated by an INFO log > > In all cases there's no failure if the target user doesn't exist, as > in the current version. > > -Bertrand (who's so happy to see Shared Neurons in action ;-) -- Karl Pauls karlpa...@gmail.com
Re: How to manage repoinit language + implementation evolutions?
Hi, On Tue, Oct 2, 2018 at 7:46 AM Karl Pauls wrote: > Can’t we stay BC and just introduce a new command that has the new behavior > and keep the old one as is?... Great idea, this is much simpler to implement and manage indeed, at the cost of making the language slightly more complicated. I think having to differentiate between service and non-service users when deleting is somewhat of an edge case, which a STRICT modifier can address - so how about: DELETE STRICT USER -> delete user only if it's NOT a service user DELETE STRICT SERVICE USER -> delete user only if it's a service user DELETE USER -> delete both service and non-service user DELETE SERVICE USER -> same but deprecated, indicated by an INFO log In all cases there's no failure if the target user doesn't exist, as in the current version. -Bertrand (who's so happy to see Shared Neurons in action ;-)
[jira] [Created] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
Timothee Maret created SLING-7969:
-
Summary: Memory leak in DiscoveryLiteDescriptor
Key: SLING-7969
URL: https://issues.apache.org/jira/browse/SLING-7969
Project: Sling
Issue Type: Bug
Components: Discovery
Affects Versions: Discovery Commons 1.0.20
Reporter: Timothee Maret
Assignee: Timothee Maret
As identified in [~volteanu]'s adaptTo
[presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
instance.
Sling discovery deals with transient states (the views, leases, etc.) and is
not caching significant amount of data. The 42MB figure for the discovery
feature seems like a symptom of a memory leak.
[~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
consumed by a Json Factory reference. There is one static JsonReaderFactory in
the discovery commons module, in the
[DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
Looking at the code, it seems that each invocation of the
[getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
method creates a JSON reader but never close it. This may may leave resources
behind as hinted by the description of the
[close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
method in the API. AFAIK, the
[getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
is invoked periodically on a relatively high frequency (< seconds) which may
be the trigger for the leak on all instances.
This is only a supposition for now, it should be investigated further, simply
by running a patched version of \{{org.apache.sling.discovery.commons}} that
make sure each JSON reader is properly closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7968) FeatureModelConverter should use FeatureProvider instead of ArtifactManager
[ https://issues.apache.org/jira/browse/SLING-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635120#comment-16635120 ] ASF GitHub Bot commented on SLING-7968: --- karlpauls commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426183192 @bosschaert, I guess that interface is roughly what @cziegeler just added to the analyser: https://github.com/apache/sling-org-apache-sling-feature-analyser/blob/master/src/main/java/org/apache/sling/feature/scanner/spi/ArtifactProvider.java Maybe we should move that interface out of the analyser into the feature.io project and make the exiting ArtifactProvider there into a subinterface or something? 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 > FeatureModelConverter should use FeatureProvider instead of ArtifactManager > --- > > Key: SLING-7968 > URL: https://issues.apache.org/jira/browse/SLING-7968 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.8.2, Feature Model Converter > 0.1.2 >Reporter: Karl Pauls >Priority: Major > Fix For: Feature Model Converter 0.1.4, Slingstart Maven Plugin > 1.8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > The feature model converter currently requires an ArtifactManager. This is > not needed and can be replaced with the less powerful FeatureProvider. > Subsequently, we can use the simpler interface to actually use the maven > resolver to resolve features in the Slingstart Maven Plugin (instead of using > a ArtifactManager when invoking the model convert. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] karlpauls commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager.
karlpauls commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426183192 @bosschaert, I guess that interface is roughly what @cziegeler just added to the analyser: https://github.com/apache/sling-org-apache-sling-feature-analyser/blob/master/src/main/java/org/apache/sling/feature/scanner/spi/ArtifactProvider.java Maybe we should move that interface out of the analyser into the feature.io project and make the exiting ArtifactProvider there into a subinterface or something? 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] [Resolved] (SLING-7941) Use streaming APIs to serialize a Feature to the related JSON representation
[
https://issues.apache.org/jira/browse/SLING-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved SLING-7941.
-
Resolution: Fixed
> Use streaming APIs to serialize a Feature to the related JSON representation
>
>
> Key: SLING-7941
> URL: https://issues.apache.org/jira/browse/SLING-7941
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Feature Model IO 0.1.4
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> We can avoid the unnecessary intermediate JSON objects creation by replacing
> current usage with {{javax.json.JsonGenerator}} APIs, when serializing a
> {{Feature}} to the related JSON representation.
> Pull request is coming, tests keep working as before.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (SLING-7779) API Region support for the Sling Feature Model
[ https://issues.apache.org/jira/browse/SLING-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reopened SLING-7779: - > API Region support for the Sling Feature Model > -- > > Key: SLING-7779 > URL: https://issues.apache.org/jira/browse/SLING-7779 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > The sling feature model should be extended with API Region support as > described here: > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7968) FeatureModelConverter should use FeatureProvider instead of ArtifactManager
[ https://issues.apache.org/jira/browse/SLING-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635110#comment-16635110 ] ASF GitHub Bot commented on SLING-7968: --- bosschaert edited a comment on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426178399 Interestingly enough I came across a similar situation when working on the API Whitelisting. In my case I need to map an Artifact (or ArtifactId) to something like an InputStream or File. If we refactor the FeatureProvider to a more general ArtifactProvider that returns an InputStream/File we might be able to use the same interface for multiple use-cases? 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 > FeatureModelConverter should use FeatureProvider instead of ArtifactManager > --- > > Key: SLING-7968 > URL: https://issues.apache.org/jira/browse/SLING-7968 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.8.2, Feature Model Converter > 0.1.2 >Reporter: Karl Pauls >Priority: Major > Fix For: Feature Model Converter 0.1.4, Slingstart Maven Plugin > 1.8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > The feature model converter currently requires an ArtifactManager. This is > not needed and can be replaced with the less powerful FeatureProvider. > Subsequently, we can use the simpler interface to actually use the maven > resolver to resolve features in the Slingstart Maven Plugin (instead of using > a ArtifactManager when invoking the model convert. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert edited a comment on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager.
bosschaert edited a comment on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426178399 Interestingly enough I came across a similar situation when working on the API Whitelisting. In my case I need to map an Artifact (or ArtifactId) to something like an InputStream or File. If we refactor the FeatureProvider to a more general ArtifactProvider that returns an InputStream/File we might be able to use the same interface for multiple use-cases? 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] [Resolved] (SLING-7779) API Region support for the Sling Feature Model
[ https://issues.apache.org/jira/browse/SLING-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved SLING-7779. - Resolution: Fixed > API Region support for the Sling Feature Model > -- > > Key: SLING-7779 > URL: https://issues.apache.org/jira/browse/SLING-7779 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > The sling feature model should be extended with API Region support as > described here: > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7968) FeatureModelConverter should use FeatureProvider instead of ArtifactManager
[ https://issues.apache.org/jira/browse/SLING-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635106#comment-16635106 ] ASF GitHub Bot commented on SLING-7968: --- bosschaert commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426178399 Interestingly enough I came across a similar situation when working on the API Whitelisting. In my case I need to map an Artifact (or ArtifactId) to something like an InputStream or File. If we refactor the FeatureProvider to a more general ArtifactProvider that returns an InputStream we might be able to use the same interface for multiple use-cases? 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 > FeatureModelConverter should use FeatureProvider instead of ArtifactManager > --- > > Key: SLING-7968 > URL: https://issues.apache.org/jira/browse/SLING-7968 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.8.2, Feature Model Converter > 0.1.2 >Reporter: Karl Pauls >Priority: Major > Fix For: Feature Model Converter 0.1.4, Slingstart Maven Plugin > 1.8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > The feature model converter currently requires an ArtifactManager. This is > not needed and can be replaced with the less powerful FeatureProvider. > Subsequently, we can use the simpler interface to actually use the maven > resolver to resolve features in the Slingstart Maven Plugin (instead of using > a ArtifactManager when invoking the model convert. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager.
bosschaert commented on issue #1: SLING-7968: Use FeatureProvider instead of ArtifactManager. URL: https://github.com/apache/sling-org-apache-sling-feature-modelconverter/pull/1#issuecomment-426178399 Interestingly enough I came across a similar situation when working on the API Whitelisting. In my case I need to map an Artifact (or ArtifactId) to something like an InputStream or File. If we refactor the FeatureProvider to a more general ArtifactProvider that returns an InputStream we might be able to use the same interface for multiple use-cases? 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
