Re: Sling 12 themes
In addition to that, it seems to me wrong to write a script which creates an output (being that html or json or whatever) and then you need an additional mechanism to modify this output. Wouldn't it be much better to create the correct output in the first place? So I think there are three places where you potentially do the modifications: 1. You modify your model which is the input to your script 2. You do it in a script 3. You reparse the output of your script and then modify it Maybe there are still use cases for 3 and then the rewriter is a good tool for it. But I sincerely hope that 95% of the use cases can already be solved with 1 or 2 - and thats were we should focus on. Carsten Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler: As usual we're giving ourselves and our users a hard time as we want to support all the possible options in the world instead of focusing on one or two options and make them as good as possible. I don't care what the solution is, but supporting 5 different ways of creating html is imho totally wrong and fragmenting our user base. Whether it is HTL or not is a different question. The current architecture of the rewriter is not optimal as it needs to reparse the output which is expensive. The servlet API has no support for streaming text based outputs so as long as we have that API in between we have a bad solution. Building on top of something where we know that its not a good thing, seems wrong to me as well. Carsten Am 24.10.2018 um 01:45 schrieb Justin Edelson: Just my 2cents as a fan of the rewriter. The problem with saying "just use HTL" (aside from what Jason said) is that it enables a separation of concerns. To say "just use HTL" implies that there is a single developer (or organization) who "owns" all the code responsible for generating HTML and has the authority to change them to suit emerging requirements (which today can be done universally via a rewriter transformer). But this isn't really the case a lot of the time -- there's multiple "owners" who are each contributing components and applying rewriter-style logic across those owners is complicated (if not impossible) to manage. This also assumes that HTL (or any other scripting language generating HTML) is actually being used properly -- in my experience, there's plenty of "raw" HTML being output from string properties and you need a way to rewrite that too. I really don't think all the rewriter use cases boil down to link rewriting. https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13 is a real-world example. But I'll need to dig through my project archive to come up with good examples. Personally, I'd suggest that HTL could be more tightly coupled to the rewriter and rather than emit a character stream which gets parsed into a SAX stream, the rewriter could be reimagined as a more generic event stream processing chain and HTL is directly providing HTML events into this chain (and given that HTL knows the output context, it could indicate as part of the event that the text content should be parsed in the case of embedded HTML). The output of JSPs could be parsed as is the current state. JSON could be handled through different event types. On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler wrote: The rewriter as it is today is pretty heavy and adds a lot of overhead to request processing. Especially as the output needs to be created first and then parsed again. There is nothing wrong with enhancing it in general. But for example if you use HTL we could provide much better and faster support ootb. I think if JSON is rendered we could do something at JSON creation time instead of needing to reparse it again as well. I agree that it gets pretty hard to come up with a solution that targets all output formats at once, even with the rewriter concept it's not that easy. But maybe we can come up with different implementations that share a single configuration. For example for link rewriting that should be possible. Carsten Am 23.10.2018 um 21:43 schrieb Daniel Klco: I don't see how we could support multiple templating languages without some sort of rewriter support. Part of the problem IMO is that the Rewriter library muddles the rewriting concept with an expectation of specifically dealing with (X)HTML. Instead it would make more sense to me to have a content agnostic library for performing content rewriting and providing a HTML, XML and (possibly) JSON implementation. On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey wrote: On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: I would rather prefer to get rid of a server side postprocessing like the rewriter. For HTL I agree with Carsten, we should probably look into a generic link rewriting mechanism which allows for custom rewriting with a nice HTL plugin. Much less overhead than a Cocoon pipeline which needs to deserialize and then serialize again... Would be interesting to
Re: Sling 12 themes
As usual we're giving ourselves and our users a hard time as we want to support all the possible options in the world instead of focusing on one or two options and make them as good as possible. I don't care what the solution is, but supporting 5 different ways of creating html is imho totally wrong and fragmenting our user base. Whether it is HTL or not is a different question. The current architecture of the rewriter is not optimal as it needs to reparse the output which is expensive. The servlet API has no support for streaming text based outputs so as long as we have that API in between we have a bad solution. Building on top of something where we know that its not a good thing, seems wrong to me as well. Carsten Am 24.10.2018 um 01:45 schrieb Justin Edelson: Just my 2cents as a fan of the rewriter. The problem with saying "just use HTL" (aside from what Jason said) is that it enables a separation of concerns. To say "just use HTL" implies that there is a single developer (or organization) who "owns" all the code responsible for generating HTML and has the authority to change them to suit emerging requirements (which today can be done universally via a rewriter transformer). But this isn't really the case a lot of the time -- there's multiple "owners" who are each contributing components and applying rewriter-style logic across those owners is complicated (if not impossible) to manage. This also assumes that HTL (or any other scripting language generating HTML) is actually being used properly -- in my experience, there's plenty of "raw" HTML being output from string properties and you need a way to rewrite that too. I really don't think all the rewriter use cases boil down to link rewriting. https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13 is a real-world example. But I'll need to dig through my project archive to come up with good examples. Personally, I'd suggest that HTL could be more tightly coupled to the rewriter and rather than emit a character stream which gets parsed into a SAX stream, the rewriter could be reimagined as a more generic event stream processing chain and HTL is directly providing HTML events into this chain (and given that HTL knows the output context, it could indicate as part of the event that the text content should be parsed in the case of embedded HTML). The output of JSPs could be parsed as is the current state. JSON could be handled through different event types. On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler wrote: The rewriter as it is today is pretty heavy and adds a lot of overhead to request processing. Especially as the output needs to be created first and then parsed again. There is nothing wrong with enhancing it in general. But for example if you use HTL we could provide much better and faster support ootb. I think if JSON is rendered we could do something at JSON creation time instead of needing to reparse it again as well. I agree that it gets pretty hard to come up with a solution that targets all output formats at once, even with the rewriter concept it's not that easy. But maybe we can come up with different implementations that share a single configuration. For example for link rewriting that should be possible. Carsten Am 23.10.2018 um 21:43 schrieb Daniel Klco: I don't see how we could support multiple templating languages without some sort of rewriter support. Part of the problem IMO is that the Rewriter library muddles the rewriting concept with an expectation of specifically dealing with (X)HTML. Instead it would make more sense to me to have a content agnostic library for performing content rewriting and providing a HTML, XML and (possibly) JSON implementation. On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey wrote: On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: I would rather prefer to get rid of a server side postprocessing like the rewriter. For HTL I agree with Carsten, we should probably look into a generic link rewriting mechanism which allows for custom rewriting with a nice HTL plugin. Much less overhead than a Cocoon pipeline which needs to deserialize and then serialize again... Would be interesting to get forward in that regard with Sling 12. There is a real world need for html post processing that is not dependent on HTL. The rewriter is already not a core component and something that is community supported so I don't think enhancing it should be much of an issue. For what it's worth though I don't like the overhead of the existing pipeline as it is anyway. HTML doesn't have anything to do with XML anymore. For JSON and client side rendering the link rewriting must be rather encapsulated on the client side as well. I don’t think Sling should provide that functionality as Sling is focusing on the server side. Missing a point here I think. If you are focusing on link rewriting, that is something that can only occur on the server side. Helps
Re: Sling 12 themes
Just my 2cents as a fan of the rewriter. The problem with saying "just use HTL" (aside from what Jason said) is that it enables a separation of concerns. To say "just use HTL" implies that there is a single developer (or organization) who "owns" all the code responsible for generating HTML and has the authority to change them to suit emerging requirements (which today can be done universally via a rewriter transformer). But this isn't really the case a lot of the time -- there's multiple "owners" who are each contributing components and applying rewriter-style logic across those owners is complicated (if not impossible) to manage. This also assumes that HTL (or any other scripting language generating HTML) is actually being used properly -- in my experience, there's plenty of "raw" HTML being output from string properties and you need a way to rewrite that too. I really don't think all the rewriter use cases boil down to link rewriting. https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13 is a real-world example. But I'll need to dig through my project archive to come up with good examples. Personally, I'd suggest that HTL could be more tightly coupled to the rewriter and rather than emit a character stream which gets parsed into a SAX stream, the rewriter could be reimagined as a more generic event stream processing chain and HTL is directly providing HTML events into this chain (and given that HTL knows the output context, it could indicate as part of the event that the text content should be parsed in the case of embedded HTML). The output of JSPs could be parsed as is the current state. JSON could be handled through different event types. On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler wrote: > The rewriter as it is today is pretty heavy and adds a lot of overhead > to request processing. Especially as the output needs to be created > first and then parsed again. > > There is nothing wrong with enhancing it in general. But for example if > you use HTL we could provide much better and faster support ootb. I > think if JSON is rendered we could do something at JSON creation time > instead of needing to reparse it again as well. > > I agree that it gets pretty hard to come up with a solution that targets > all output formats at once, even with the rewriter concept it's not that > easy. But maybe we can come up with different implementations that share > a single configuration. For example for link rewriting that should be > possible. > > > Carsten > > Am 23.10.2018 um 21:43 schrieb Daniel Klco: > > I don't see how we could support multiple templating languages without > some > > sort of rewriter support. > > > > Part of the problem IMO is that the Rewriter library muddles the > rewriting > > concept with an expectation of specifically dealing with (X)HTML. Instead > > it would make more sense to me to have a content agnostic library for > > performing content rewriting and providing a HTML, XML and (possibly) > JSON > > implementation. > > > > On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey wrote: > > > >> > >> On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: > >>> I would rather prefer to get rid of a server side postprocessing like > >>> the rewriter. For HTL I agree with Carsten, we should probably look > into > >>> a generic link rewriting mechanism which allows for custom rewriting > >>> with a nice HTL plugin. Much less overhead than a Cocoon pipeline which > >>> needs to deserialize and then serialize again... > >>> Would be interesting to get forward in that regard with Sling 12. > >> > >> There is a real world need for html post processing that is not > dependent > >> on HTL. The rewriter is already not a core component and something that > is > >> community supported so I don't think enhancing it should be much of an > >> issue. For what it's worth though I don't like the overhead of the > existing > >> pipeline as it is anyway. HTML doesn't have anything to do with XML > anymore. > >> > >>> For JSON and client side rendering the link rewriting must be rather > >>> encapsulated on the client side as well. I don’t think Sling should > >>> provide that functionality as Sling is focusing on the server side. > >> > >> Missing a point here I think. If you are focusing on link rewriting, > that > >> is something that can only occur on the server side. Helps with > >> multi-tenancy and cross linking. > >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Sling 12 themes
The rewriter as it is today is pretty heavy and adds a lot of overhead to request processing. Especially as the output needs to be created first and then parsed again. There is nothing wrong with enhancing it in general. But for example if you use HTL we could provide much better and faster support ootb. I think if JSON is rendered we could do something at JSON creation time instead of needing to reparse it again as well. I agree that it gets pretty hard to come up with a solution that targets all output formats at once, even with the rewriter concept it's not that easy. But maybe we can come up with different implementations that share a single configuration. For example for link rewriting that should be possible. Carsten Am 23.10.2018 um 21:43 schrieb Daniel Klco: I don't see how we could support multiple templating languages without some sort of rewriter support. Part of the problem IMO is that the Rewriter library muddles the rewriting concept with an expectation of specifically dealing with (X)HTML. Instead it would make more sense to me to have a content agnostic library for performing content rewriting and providing a HTML, XML and (possibly) JSON implementation. On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey wrote: On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: I would rather prefer to get rid of a server side postprocessing like the rewriter. For HTL I agree with Carsten, we should probably look into a generic link rewriting mechanism which allows for custom rewriting with a nice HTL plugin. Much less overhead than a Cocoon pipeline which needs to deserialize and then serialize again... Would be interesting to get forward in that regard with Sling 12. There is a real world need for html post processing that is not dependent on HTL. The rewriter is already not a core component and something that is community supported so I don't think enhancing it should be much of an issue. For what it's worth though I don't like the overhead of the existing pipeline as it is anyway. HTML doesn't have anything to do with XML anymore. For JSON and client side rendering the link rewriting must be rather encapsulated on the client side as well. I don’t think Sling should provide that functionality as Sling is focusing on the server side. Missing a point here I think. If you are focusing on link rewriting, that is something that can only occur on the server side. Helps with multi-tenancy and cross linking. -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling 12 themes
I don't see how we could support multiple templating languages without some sort of rewriter support. Part of the problem IMO is that the Rewriter library muddles the rewriting concept with an expectation of specifically dealing with (X)HTML. Instead it would make more sense to me to have a content agnostic library for performing content rewriting and providing a HTML, XML and (possibly) JSON implementation. On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey wrote: > > On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: > > I would rather prefer to get rid of a server side postprocessing like > > the rewriter. For HTL I agree with Carsten, we should probably look into > > a generic link rewriting mechanism which allows for custom rewriting > > with a nice HTL plugin. Much less overhead than a Cocoon pipeline which > > needs to deserialize and then serialize again... > > Would be interesting to get forward in that regard with Sling 12. > > There is a real world need for html post processing that is not dependent > on HTL. The rewriter is already not a core component and something that is > community supported so I don't think enhancing it should be much of an > issue. For what it's worth though I don't like the overhead of the existing > pipeline as it is anyway. HTML doesn't have anything to do with XML anymore. > > > For JSON and client side rendering the link rewriting must be rather > > encapsulated on the client side as well. I don’t think Sling should > > provide that functionality as Sling is focusing on the server side. > > Missing a point here I think. If you are focusing on link rewriting, that > is something that can only occur on the server side. Helps with > multi-tenancy and cross linking. >
Re: Sling 12 themes
Am Di., 23. Okt. 2018 um 16:29 Uhr schrieb Robert Munteanu < romb...@apache.org>: > > I think it would be an interesting and worthwhile exercise to see what > various contributors would like to see as the major themes of Sling 12. > > I would like to have some cleanup done * get rid of dependencies to old versions (e.g. we still have modules depending on Oak 1.4) * Would be great to improve consistency in terms of tests and test frameworks, so we have examples for writing tests properly (both unit and integration tests) And of course the documentation can always be improved. Would absolutely love if we could also have the "old" documentation for reference (there are people out there which cannot always use the most recent version of Sling, therefor having the old docs available would be beneficial (next to the old API docs). -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
Re: [VOTE] Release Apache Sling Models Impl version 1.4.10
On Friday 19 October 2018 10:50:43 Daniel Klco wrote: > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12342851 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1999/ +1 O.
Re: Archetype naming (was: [VOTE] Release Apache Sling 11)
On Tuesday 23 October 2018 10:38:52 Robert Munteanu wrote: > Hi Olli, Hi Robert, > On Mon, 2018-10-22 at 22:08 +0200, Oliver Lietz wrote: > > > > - sling-launchpad-archetype 1.0.8 > > > > should be sling-starter-archetype > > Hm, maybe? 'Launchpad' is the term we use for the utilities that allow > setting up a Sling application, while 'starter' is the term for our own > sample/demo application. > > Maybe sling-application-archetype would be better, decoupling the > concept from our own internal naming for tooling? sorry, I mean sling-slingstart-archetype. We don't have a module named sling- launchpad-archetype, right? Regards, O. > Thanks, > > Robert
Re: Sling 12 themes
On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: > I would rather prefer to get rid of a server side postprocessing like > the rewriter. For HTL I agree with Carsten, we should probably look into > a generic link rewriting mechanism which allows for custom rewriting > with a nice HTL plugin. Much less overhead than a Cocoon pipeline which > needs to deserialize and then serialize again... > Would be interesting to get forward in that regard with Sling 12. There is a real world need for html post processing that is not dependent on HTL. The rewriter is already not a core component and something that is community supported so I don't think enhancing it should be much of an issue. For what it's worth though I don't like the overhead of the existing pipeline as it is anyway. HTML doesn't have anything to do with XML anymore. > For JSON and client side rendering the link rewriting must be rather > encapsulated on the client side as well. I don’t think Sling should > provide that functionality as Sling is focusing on the server side. Missing a point here I think. If you are focusing on link rewriting, that is something that can only occur on the server side. Helps with multi-tenancy and cross linking.
Re: Sling 12 themes
I would rather prefer to get rid of a server side postprocessing like the rewriter. For HTL I agree with Carsten, we should probably look into a generic link rewriting mechanism which allows for custom rewriting with a nice HTL plugin. Much less overhead than a Cocoon pipeline which needs to deserialize and then serialize again... Would be interesting to get forward in that regard with Sling 12. For JSON and client side rendering the link rewriting must be rather encapsulated on the client side as well. I don’t think Sling should provide that functionality as Sling is focusing on the server side. Konrad > Am 23.10.2018 um 19:08 schrieb Ruben Reusser : > > since we now have sling models and sling model exporters I would also kind of > like a rewrite chain on json to shorten URLs for example. > > Ruben > > >> On 10/23/2018 9:59 AM, Jason E Bailey wrote: >> It depends on what I'm writing and where, whether it's server side or front >> end. But in general I use a combination of html/jsp and models for the >> majority of my code. The delta between what the html looks like between >> these implementations is usually minor. >> >> I do like the contextual awareness that HTL brings, I was doing something >> similar in the rewriter before HTL became a thing. But I like it as a tool >> in the chest. Not as something that is required. >> >> - Jason >> >>> On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote: >>> So what do you like for creating html? >>> >>> Carsten >>> Am 23.10.2018 um 18:42 schrieb Jason E Bailey: 1. I don't use HTL 2. When I last mucked with HTL, and this could have changed, it had problems itself with HTML5 3. When I've used the rewriter it's because I need something centralized that is modifying HTML with out regard to where the HTML is coming from. 4. I dislike HTL 5. I really dislike HTL - Jason > On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote: > Why do we need a rewriter if we're using HTL? I think a plugin model to > influence or inspect the html using HTL is way more efficient as HTL > already knowns the context of an element. > > Regards > Carsten > >> Am 23.10.2018 um 18:02 schrieb Jason E Bailey: >> >>> On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: >>> A couple thoughts from my end: >>> - Cleanup of the Rewriter, providing a HTML 5 pipeline >> I was going to start working on the HTML 5 rewriter next week. >> >> - Jason >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >
Re: Sling 12 themes
since we now have sling models and sling model exporters I would also kind of like a rewrite chain on json to shorten URLs for example. Ruben On 10/23/2018 9:59 AM, Jason E Bailey wrote: It depends on what I'm writing and where, whether it's server side or front end. But in general I use a combination of html/jsp and models for the majority of my code. The delta between what the html looks like between these implementations is usually minor. I do like the contextual awareness that HTL brings, I was doing something similar in the rewriter before HTL became a thing. But I like it as a tool in the chest. Not as something that is required. - Jason On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote: So what do you like for creating html? Carsten Am 23.10.2018 um 18:42 schrieb Jason E Bailey: 1. I don't use HTL 2. When I last mucked with HTL, and this could have changed, it had problems itself with HTML5 3. When I've used the rewriter it's because I need something centralized that is modifying HTML with out regard to where the HTML is coming from. 4. I dislike HTL 5. I really dislike HTL - Jason On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote: Why do we need a rewriter if we're using HTL? I think a plugin model to influence or inspect the html using HTL is way more efficient as HTL already knowns the context of an element. Regards Carsten Am 23.10.2018 um 18:02 schrieb Jason E Bailey: On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: A couple thoughts from my end: - Cleanup of the Rewriter, providing a HTML 5 pipeline I was going to start working on the HTML 5 rewriter next week. - Jason -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling 12 themes
It depends on what I'm writing and where, whether it's server side or front end. But in general I use a combination of html/jsp and models for the majority of my code. The delta between what the html looks like between these implementations is usually minor. I do like the contextual awareness that HTL brings, I was doing something similar in the rewriter before HTL became a thing. But I like it as a tool in the chest. Not as something that is required. - Jason On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote: > So what do you like for creating html? > > Carsten > > Am 23.10.2018 um 18:42 schrieb Jason E Bailey: > > 1. I don't use HTL > > > > 2. When I last mucked with HTL, and this could have changed, it had > > problems itself with HTML5 > > > > 3. When I've used the rewriter it's because I need something centralized > > that is modifying HTML with out regard to where the HTML is coming from. > > > > 4. I dislike HTL > > > > 5. I really dislike HTL > > > > - Jason > > > > On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote: > >> Why do we need a rewriter if we're using HTL? I think a plugin model to > >> influence or inspect the html using HTL is way more efficient as HTL > >> already knowns the context of an element. > >> > >> Regards > >> Carsten > >> > >> Am 23.10.2018 um 18:02 schrieb Jason E Bailey: > >>> > >>> > >>> On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: > A couple thoughts from my end: > - Cleanup of the Rewriter, providing a HTML 5 pipeline > >>> > >>> I was going to start working on the HTML 5 rewriter next week. > >>> > >>> - Jason > >>> > >> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Sling 12 themes
So what do you like for creating html? Carsten Am 23.10.2018 um 18:42 schrieb Jason E Bailey: 1. I don't use HTL 2. When I last mucked with HTL, and this could have changed, it had problems itself with HTML5 3. When I've used the rewriter it's because I need something centralized that is modifying HTML with out regard to where the HTML is coming from. 4. I dislike HTL 5. I really dislike HTL - Jason On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote: Why do we need a rewriter if we're using HTL? I think a plugin model to influence or inspect the html using HTL is way more efficient as HTL already knowns the context of an element. Regards Carsten Am 23.10.2018 um 18:02 schrieb Jason E Bailey: On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: A couple thoughts from my end: - Cleanup of the Rewriter, providing a HTML 5 pipeline I was going to start working on the HTML 5 rewriter next week. - Jason -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling 12 themes
Why do we need a rewriter if we're using HTL? I think a plugin model to influence or inspect the html using HTL is way more efficient as HTL already knowns the context of an element. Regards Carsten Am 23.10.2018 um 18:02 schrieb Jason E Bailey: On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: A couple thoughts from my end: - Cleanup of the Rewriter, providing a HTML 5 pipeline I was going to start working on the HTML 5 rewriter next week. - Jason -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling 12 themes
On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote: > A couple thoughts from my end: > - Cleanup of the Rewriter, providing a HTML 5 pipeline I was going to start working on the HTML 5 rewriter next week. - Jason
Re: Sling 12 themes
1. Creating a resource provider to use as the default resource provider for the starter installation 2. Define a Resource 3. Define a Resource Type hierarchy 4. Convert all generated HTML to HTML5 standards 5. Fix the website - Jason On Tue, Oct 23, 2018, at 10:29 AM, Robert Munteanu wrote: > Hi, > > Now that Sling 11 is out, we should be thinking about Sling 12 already > :-) . > > Each Sling release brings in hundreds of individual changes in the form > of bug fixes and incremental improvements. On top of that, we also have > major features or themes for the release, such as: > > * updating to OSGi R7 (Sling 11) > * Github migration (~Sling 10) > * Refreshing the default ACL setup (Sling 11) > * Enhanced Java 9+ support (Sling 10,11) > > I think it would be an interesting and worthwhile exercise to see what > various contributors would like to see as the major themes of Sling 12. > > So, fire away :-) > > Thanks, > > Robert > >
[GitHub] philipmundt opened a new pull request #10: SLING-8047 ExportServlet does not write to output stream
philipmundt opened a new pull request #10: SLING-8047 ExportServlet does not write to output stream URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/10 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: [VOTE] Release Apache Sling Distributed Event Admin 1.1.4
On Tue, 2018-10-23 at 17:21 +0200, Robert Munteanu wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[VOTE] Release Apache Sling Distributed Event Admin 1.1.4
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12339956 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2001 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 2001 /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. Thanks, Robert
Re: [VOTE] Release Apache Sling Models Impl version 1.4.10
+1 Cheers, Stefan On 19.10.18 16:50, Daniel Klco wrote: Hi, We solved 5 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12342851 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1999/ 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 1999 /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.
Re: Sling 12 themes
A couple thoughts from my end: - Integration with Apache OpenWisk - expose Apache Sling content and output via dedicated endpoints and functions - Add an integration layer for jobs to be invoked from Sling and completed in OpenWisk - Cleanup of the Rewriter, providing a HTML 5 pipeline - Security features -- try to make it easier to make a "default" installation of Sling secure: - Login failure lockout - Filter selectors / suffixes - Deduplicate slashes - https://speakerdeck.com/0ang3el/hunting-for-security-bugs-in-aem-webapps On Tue, Oct 23, 2018 at 10:30 AM Robert Munteanu wrote: > Hi, > > Now that Sling 11 is out, we should be thinking about Sling 12 already > :-) . > > Each Sling release brings in hundreds of individual changes in the form > of bug fixes and incremental improvements. On top of that, we also have > major features or themes for the release, such as: > > * updating to OSGi R7 (Sling 11) > * Github migration (~Sling 10) > * Refreshing the default ACL setup (Sling 11) > * Enhanced Java 9+ support (Sling 10,11) > > I think it would be an interesting and worthwhile exercise to see what > various contributors would like to see as the major themes of Sling 12. > > So, fire away :-) > > Thanks, > > Robert > > >
[jira] [Resolved] (SLING-8002) DistributedEventReceiver utilizes long-running session
[
https://issues.apache.org/jira/browse/SLING-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-8002.
Resolution: Fixed
Applied in [sling-org-apache-sling-event-dea commit
b6644e5|https://github.com/apache/sling-org-apache-sling-event-dea/commit/b6644e5],
thanks [~joerghoh] for the patch!
> DistributedEventReceiver utilizes long-running session
> --
>
> Key: SLING-8002
> URL: https://issues.apache.org/jira/browse/SLING-8002
> Project: Sling
> Issue Type: Improvement
> Components: Event
>Affects Versions: Distributed Event Admin 1.1.2
>Reporter: Jörg Hoh
>Assignee: Robert Munteanu
>Priority: Major
> Attachments: SLING-8002.patch
>
>
> We recently came across this warning in our logs. Looks like the
> DistributedEventReceiver uses a long-running session, thus causing warnings
> from Oak.
> {noformat}
> 10.10.2018 10:02:37.620 *WARN* [Thread-51]
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
> idle for 5 minutes and might be out of date. Consider using a fresh session
> or explicitly refresh the session.
> java.lang.Exception: The session was created here:
> at
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
>
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:150)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:241)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:177)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:174)
>
> at
> java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:729)
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:174)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:166)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
>
> at
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96)
>
> at
> org.apache.sling.event.dea.impl.DistributedEventReceiver$1.run(DistributedEventReceiver.java:139)
>
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> Either the scope of the session should be reduced, or the session should be
> refreshed before writing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8002) DistributedEventReceiver utilizes long-running session
[
https://issues.apache.org/jira/browse/SLING-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-8002:
---
Fix Version/s: Distributed Event Admin 1.1.4
> DistributedEventReceiver utilizes long-running session
> --
>
> Key: SLING-8002
> URL: https://issues.apache.org/jira/browse/SLING-8002
> Project: Sling
> Issue Type: Improvement
> Components: Event
>Affects Versions: Distributed Event Admin 1.1.2
>Reporter: Jörg Hoh
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Distributed Event Admin 1.1.4
>
> Attachments: SLING-8002.patch
>
>
> We recently came across this warning in our logs. Looks like the
> DistributedEventReceiver uses a long-running session, thus causing warnings
> from Oak.
> {noformat}
> 10.10.2018 10:02:37.620 *WARN* [Thread-51]
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
> idle for 5 minutes and might be out of date. Consider using a fresh session
> or explicitly refresh the session.
> java.lang.Exception: The session was created here:
> at
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
>
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:150)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:241)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:177)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:174)
>
> at
> java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:729)
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:174)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:166)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
>
> at
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96)
>
> at
> org.apache.sling.event.dea.impl.DistributedEventReceiver$1.run(DistributedEventReceiver.java:139)
>
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> Either the scope of the session should be reduced, or the session should be
> refreshed before writing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8002) DistributedEventReceiver utilizes long-running session
[
https://issues.apache.org/jira/browse/SLING-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned SLING-8002:
--
Assignee: Robert Munteanu
> DistributedEventReceiver utilizes long-running session
> --
>
> Key: SLING-8002
> URL: https://issues.apache.org/jira/browse/SLING-8002
> Project: Sling
> Issue Type: Improvement
> Components: Event
>Affects Versions: Distributed Event Admin 1.1.2
>Reporter: Jörg Hoh
>Assignee: Robert Munteanu
>Priority: Major
> Attachments: SLING-8002.patch
>
>
> We recently came across this warning in our logs. Looks like the
> DistributedEventReceiver uses a long-running session, thus causing warnings
> from Oak.
> {noformat}
> 10.10.2018 10:02:37.620 *WARN* [Thread-51]
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
> idle for 5 minutes and might be out of date. Consider using a fresh session
> or explicitly refresh the session.
> java.lang.Exception: The session was created here:
> at
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
>
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:150)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:241)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:177)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:174)
>
> at
> java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:729)
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:174)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:166)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
>
> at
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96)
>
> at
> org.apache.sling.event.dea.impl.DistributedEventReceiver$1.run(DistributedEventReceiver.java:139)
>
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> Either the scope of the session should be reduced, or the session should be
> refreshed before writing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Models Impl version 1.4.10
On Fri, 2018-10-19 at 10:50 -0400, Daniel Klco wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Sling 12 themes
Hi, Now that Sling 11 is out, we should be thinking about Sling 12 already :-) . Each Sling release brings in hundreds of individual changes in the form of bug fixes and incremental improvements. On top of that, we also have major features or themes for the release, such as: * updating to OSGi R7 (Sling 11) * Github migration (~Sling 10) * Refreshing the default ACL setup (Sling 11) * Enhanced Java 9+ support (Sling 10,11) I think it would be an interesting and worthwhile exercise to see what various contributors would like to see as the major themes of Sling 12. So, fire away :-) Thanks, Robert
Re: [VOTE] Release Apache Sling Models Impl version 1.4.10
Any other votes? On Fri, Oct 19, 2018 at 10:57 AM Daniel Klco wrote: > My +1 > > On Fri, Oct 19, 2018 at 10:50 AM Daniel Klco wrote: > >> Hi, >> >> We solved 5 issues in this release: >> https://issues.apache.org/jira/projects/SLING/versions/12342851 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachesling-1999/ >> >> 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 1999 /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] [Assigned] (SLING-7909) Deploy Sling 11 docker image to DockerHub
[ https://issues.apache.org/jira/browse/SLING-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7909: -- Assignee: Robert Munteanu > Deploy Sling 11 docker image to DockerHub > - > > Key: SLING-7909 > URL: https://issues.apache.org/jira/browse/SLING-7909 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-7911) Send announcement to u...@sling.apache.org and annou...@apache.org
[ https://issues.apache.org/jira/browse/SLING-7911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7911: -- Assignee: Robert Munteanu > Send announcement to u...@sling.apache.org and annou...@apache.org > -- > > Key: SLING-7911 > URL: https://issues.apache.org/jira/browse/SLING-7911 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7909) Deploy Sling 11 docker image to DockerHub
[ https://issues.apache.org/jira/browse/SLING-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7909. Resolution: Fixed > Deploy Sling 11 docker image to DockerHub > - > > Key: SLING-7909 > URL: https://issues.apache.org/jira/browse/SLING-7909 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7908) Deploy API documentation for Sling 11
[ https://issues.apache.org/jira/browse/SLING-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7908. Resolution: Fixed > Deploy API documentation for Sling 11 > - > > Key: SLING-7908 > URL: https://issues.apache.org/jira/browse/SLING-7908 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7906) Release Sling Starter 11 and associated artifacts
[ https://issues.apache.org/jira/browse/SLING-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7906. Resolution: Fixed > Release Sling Starter 11 and associated artifacts > - > > Key: SLING-7906 > URL: https://issues.apache.org/jira/browse/SLING-7906 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > - starter 11 > - launchpad.testing and associated projects > - Maven archetypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-7908) Deploy API documentation for Sling 11
[ https://issues.apache.org/jira/browse/SLING-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7908: -- Assignee: Robert Munteanu > Deploy API documentation for Sling 11 > - > > Key: SLING-7908 > URL: https://issues.apache.org/jira/browse/SLING-7908 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7634) Launchpad testing fails with Java 10
[
https://issues.apache.org/jira/browse/SLING-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7634.
--
> Launchpad testing fails with Java 10
>
>
> Key: SLING-7634
> URL: https://issues.apache.org/jira/browse/SLING-7634
> Project: Sling
> Issue Type: Bug
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Launchpad Testing 11
>
>
> It seems the version of the failsafe plugin we're using is not compatible
> with Java 10:
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.20.1:integration-test
> (default) on project org.apache.sling.launchpad.testing: Execution default of
> goal org.apache.maven.plugins:maven-failsafe-plugin:2.20.1:integration-test
> failed. NullPointerException -> [Help 1]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7106) JaxbMarshallingTest fails with Java 9
[
https://issues.apache.org/jira/browse/SLING-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7106.
--
> JaxbMarshallingTest fails with Java 9
> -
>
> Key: SLING-7106
> URL: https://issues.apache.org/jira/browse/SLING-7106
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Launchpad Testing 11
>
>
> {noformat}Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.005 sec <<< FAILURE! - in
> org.apache.sling.launchpad.webapp.integrationtest.jaxb.JaxbMarshallingTest
> testJaxbEntityIsMarshalled(org.apache.sling.launchpad.webapp.integrationtest.jaxb.JaxbMarshallingTest)
> Time elapsed: 0.005 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Expected status 200 for
> http://localhost:41000/bin/jaxb.xml (content= "-//IETF//DTD HTML 2.0//EN">
>
>
> 404 Resource at /bin/jaxb.xml not found: No resource
> found
>
>
> Resource at /bin/jaxb.xml not found: No resource found
> (404)
> The requested URL /bin/jaxb.xml resulted in an error in
> org.apache.sling.servlets.resolver.internal.defaults.DefaultErrorHandlerServlet.
> Request Progress:
>
> 0 TIMER_START{Request Processing}
> 1 COMMENT timer_end format is {elapsed microseconds,timer
> name} optional message
> 4 LOG Method=GET, PathInfo=null
> 5 TIMER_START{handleSecurity}
>1423 TIMER_END{1416,handleSecurity} authenticator
> org.apache.sling.auth.core.impl.SlingAuthenticator@4d8e3503 returns true
>2207 TIMER_START{ResourceResolution}
>2405 TIMER_END{197,ResourceResolution} URI=/bin/jaxb.xml resolves to
> Resource=NonExistingResource, path=/bin/jaxb.xml
>2411 LOG Resource Path Info: SlingRequestPathInfo:
> path=/bin/jaxb.xml, selectorString=null,
> extension=xml, suffix=null
>2411 TIMER_START{ServletResolution}
>2413 TIMER_START{resolveServlet(/bin/jaxb.xml)}
>2708 TIMER_END{294,resolveServlet(/bin/jaxb.xml)} Using servlet
> org.apache.sling.servlets.get.DefaultGetServlet
>2711 TIMER_END{299,ServletResolution} URI=/bin/jaxb.xml handled by
> Servlet=org.apache.sling.servlets.get.DefaultGetServlet
>2713 LOG Applying Requestfilters
>2715 LOG Calling filter: org.apache.sling.i18n.impl.I18NFilter
>2717 LOG Calling filter:
> org.apache.sling.launchpad.testservices.filters.SlingFilter
>2723 LOG Calling filter:
> org.apache.sling.launchpad.testservices.filters.NoPropertyFilter
>2727 LOG Calling filter:
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter
>2730 LOG Applying Componentfilters
>2733 TIMER_START{org.apache.sling.servlets.get.DefaultGetServlet#0}
>2782 TIMER_END{47,org.apache.sling.servlets.get.DefaultGetServlet#0}
>2814 LOG Filter timing:
> filter=org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter,
> inner=0, total=0, outer=0
>2816 LOG Filter timing:
> filter=org.apache.sling.launchpad.testservices.filters.SlingFilterWithPattern,
> inner=0, total=0, outer=0
>2817 LOG Filter timing:
> filter=org.apache.sling.launchpad.testservices.filters.NoPropertyFilter,
> inner=0, total=0, outer=0
>2819 LOG Filter timing:
> filter=org.apache.sling.launchpad.testservices.filters.SlingFilter, inner=0,
> total=0, outer=0
>2892 LOG Applying Error filters
>2894 LOG Calling filter: org.apache.sling.i18n.impl.I18NFilter
>2900 TIMER_START{handleError:status=404}
>3084 TIMER_END{182,handleError:status=404} Using handler
> org.apache.sling.servlets.resolver.internal.defaults.DefaultErrorHandlerServlet
>3195 TIMER_END{3194,Request Processing} Dumping
> SlingRequestProgressTracker Entries
>
>
> ApacheSling/2.6 (jetty/9.3.20.v20170531, Java HotSpot(TM) 64-Bit
> Server VM 9, Linux 3.19.0-25-generic amd64)
>
>
> ) expected:<200> but was:<404>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:457)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:432)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:424)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:419)
> at
> org.apache.sling.launchpad.webapp.integrationtest.jaxb.JaxbMarshallingTest.testJaxbEntityIsMarshalled(JaxbMarshallingTest.java:34){noformat}
--
This message was sent by Atlassian
[jira] [Closed] (SLING-7890) JSON-related IT failures when upgrading sling.servlets to 2.1.34
[
https://issues.apache.org/jira/browse/SLING-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7890.
--
> JSON-related IT failures when upgrading sling.servlets to 2.1.34
>
>
> Key: SLING-7890
> URL: https://issues.apache.org/jira/browse/SLING-7890
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Get 2.1.34
>Reporter: Robert Munteanu
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: Launchpad Integration Tests 1.0.8, Servlets Get 2.1.36
>
>
> With the following change in the sling starter
> {noformat}diff --git a/src/main/provisioning/sling.txt
> b/src/main/provisioning/sling.txt
> index 0f76c0b..4904fc3 100644
> --- a/src/main/provisioning/sling.txt
> +++ b/src/main/provisioning/sling.txt
> @@ -62,7 +62,7 @@
> org.apache.sling/org.apache.sling.resourceresolver/1.6.6
> org.apache.sling/org.apache.sling.serviceusermapper/1.4.0
> org.apache.sling/org.apache.sling.serviceuser.webconsole/1.0.0
> -org.apache.sling/org.apache.sling.servlets.get/2.1.30
> +org.apache.sling/org.apache.sling.servlets.get/2.1.34
> org.apache.sling/org.apache.sling.servlets.post/2.3.26
> org.apache.sling/org.apache.sling.servlets.resolver/2.4.22
> org.apache.sling/org.apache.sling.xss/2.0.12
> {noformat}
> I get multiple IT failures, and the root cause seems top be
> {noformat}java.lang.ClassCastException:
> org.apache.johnzon.core.JsonObjectImpl cannot be cast to javax.json.JsonArray
> at
> org.apache.sling.servlets.get.impl.util.JsonToText.valueToString(JsonToText.java:164)
> at
> org.apache.sling.servlets.get.impl.util.JsonToText.prettyPrint(JsonToText.java:209)
> at
> org.apache.sling.servlets.get.impl.VersionInfoServlet.doGet(VersionInfoServlet.java:124)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
> at
> org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:82)
> at
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:282)
> at
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:82)
> at
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:107)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:78)
> at
> org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47)
> at
> org.apache.sling.launchpad.testservices.filters.NoPropertyFilter.doFilter(NoPropertyFilter.java:25)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> at
> org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47)
> at
> org.apache.sling.launchpad.testservices.filters.SlingFilter.doFilter(SlingFilter.java:25)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131)
> at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:72)
> at
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:151)
> at
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:234)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86)
> at
> org.apache.sling.junit.impl.servlet.TestLogServlet$TestNameLoggingFilter.doFilter(TestLogServlet.java:257)
> at
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
> at
>
[jira] [Closed] (SLING-7553) Sling POST servlet - expand Patch method integration tests.
[ https://issues.apache.org/jira/browse/SLING-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7553. -- > Sling POST servlet - expand Patch method integration tests. > --- > > Key: SLING-7553 > URL: https://issues.apache.org/jira/browse/SLING-7553 > Project: Sling > Issue Type: Test > Components: Servlets >Affects Versions: Launchpad Integration Tests 1.0.6 >Reporter: John Logan >Assignee: Robert Munteanu >Priority: Minor > Fix For: Launchpad Integration Tests 1.0.8 > > Attachments: > sling-org-apache-sling-launchpad-integration-tests.patch.gz > > > Per the discussion at: > [https://lists.apache.org/thread.html/a57cec24f459fa0972c93ef4a2759755435a77d6a9c590e7a23440d4@%3Cusers.sling.apache.org%3E] > I was trying to include an empty string[] property in nodes created with the > POST servlet to avoid errors when adapting the nodes to Sling models, and > found that the Patch method supported this by adding and removing a property > on a newly created node in the same operation. > > At present this behavior is undocumented. If we wish to clarify the > behavior, it seems that there are two possibilities: > * Document the current behavior (it appears that Patch operations are > applied in sequence). For this case, I have attached a patch to the > integration tests that tests adding and removing a property for a new node, > as well as removing and adding a property. > * Update the documentation to state that the behavior for adding and > removing in the same operation is unspecified and therefore should not be > relied upon. > I have no preference, as I've since switched to the more natural approach of > using a default value attribute on the model classes to solve my original > problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7832) ResourceResolverProxyTest fails: write(param) is only valid in arrays
[
https://issues.apache.org/jira/browse/SLING-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7832.
--
> ResourceResolverProxyTest fails: write(param) is only valid in arrays
> -
>
> Key: SLING-7832
> URL: https://issues.apache.org/jira/browse/SLING-7832
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: Launchpad Integration Tests 1.0.8, Launchpad Testing
> Services 2.0.16
>
>
> This test consistently fails locally and on Jenkins:
> {noformat}javax.json.stream.JsonGenerationException: write(param) is only
> valid in arrays
> at
> org.apache.sling.launchpad.webapp.integrationtest.ResourceResolverProxyTest.runWriteableResourcesTest(ResourceResolverProxyTest.java:26){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7485) Do not rely on Launchpad Content
[ https://issues.apache.org/jira/browse/SLING-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7485. -- > Do not rely on Launchpad Content > > > Key: SLING-7485 > URL: https://issues.apache.org/jira/browse/SLING-7485 > Project: Sling > Issue Type: Improvement > Components: Karaf, Launchpad, Testing >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Launchpad Content 2.0.14, Karaf Launchpad Integration > Tests (Oak Tar) 0.0.2, Launchpad Integration Tests 1.0.8, Launchpad Test > Services 2.0.14 > > > ITs should not rely on Launchpad Content but content in Launchpad Test > Services. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7950) Fix ITs with Oak 1.8
[
https://issues.apache.org/jira/browse/SLING-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7950.
--
> Fix ITs with Oak 1.8
>
>
> Key: SLING-7950
> URL: https://issues.apache.org/jira/browse/SLING-7950
> Project: Sling
> Issue Type: Sub-task
> Components: Launchpad, Oak, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Launchpad Integration Tests 1.0.8
>
>
> Updating to Oak 1.8.7 results in the following failures:
> {noformat}[ERROR] Failures:
> [ERROR] AnonymousAccessTest.testAnonymousContent:99->assertContent:85
> Expected status 200 for
> http://localhost:41000/ANON_CAN_READ/AnonymousAccessTest/789235c4-d3b2-43b3-a163-aadb95cdd56b/test_text_789235c4_d.txt
> (content=) expected:<200> but was:<401>
> [ERROR] AnonymousAccessTest.testAnonymousContent:101 Expecting status 404
> when testing outside of anonymous access subtree expected:<404> but was:<401>
> [ERROR]
> AuthRequestLoginTest.testForcedLogin:40->HttpTestBase.getContent:419->HttpTestBase.getContent:424->HttpTestBase.getContent:432->HttpTestBase.getContent:457
> Expected status 200 for
> http://localhost:41000/system/sling/info.sessionInfo.json (content=)
> expected:<200> but was:<401>
> [ERROR] RedirectOnLogoutTest.testRedirectToResourceAfterLogout:70 Expected
> redirect expected:<302> but was:<401>
> [ERROR] Errors:
> [ERROR] DavExDisabledAnonAccessTest>DavExIntegrationTest.setUp:47 »
> NoClassDefFound or...
> [ERROR] DavExDisabledAnonAccessTest>DavExIntegrationTest.setUp:47 »
> NoClassDefFound or...
> [ERROR] DavExIntegrationTest.setUp:47 » NoClassDefFound
> org/apache/jackrabbit/webdav/c...
> [ERROR] DavExIntegrationTest.setUp:47 » NoClassDefFound
> org/apache/jackrabbit/webdav/c...
> [INFO]
> [ERROR] Tests run: 655, Failures: 4, Errors: 4, Skipped: 1{noformat}
> The changes that support this are at
> https://github.com/apache/sling-org-apache-sling-starter/tree/feature/oak-1.8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7834) Transform ResourceResolverProxyTest into a teleported test
[ https://issues.apache.org/jira/browse/SLING-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7834. -- > Transform ResourceResolverProxyTest into a teleported test > -- > > Key: SLING-7834 > URL: https://issues.apache.org/jira/browse/SLING-7834 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: Launchpad Integration Tests 1.0.8, Launchpad Testing > Services 2.0.16 > > > We need to debug the ResourceResolverProxyTest for SLING-7832. That's an old > style remote test which are not convenient to troubleshoot, I'll transform it > into a more modern teleported test to make that easier. > This ticket can then also serve as an example to convert more tests when the > need arises. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7488) Upgrade Tinybundles to 3.0.0
[ https://issues.apache.org/jira/browse/SLING-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7488. -- > Upgrade Tinybundles to 3.0.0 > > > Key: SLING-7488 > URL: https://issues.apache.org/jira/browse/SLING-7488 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: JUnit Tests Teleporter 1.0.18 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7312) Java 9 requires javax.annotation to be added to the classpath
[
https://issues.apache.org/jira/browse/SLING-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7312.
--
> Java 9 requires javax.annotation to be added to the classpath
> -
>
> Key: SLING-7312
> URL: https://issues.apache.org/jira/browse/SLING-7312
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Starter 11
>
>
> When running on Java 9 post SLING-7186 startup fails due to the
> {{javax.annotation}} package no longer being exported by default, e.g.
> {noformat}org.osgi.framework.BundleException: Unable to resolve
> org.apache.sling.installer.core [2](R 2.0): missing requirement
> [org.apache.sling.installer.core [2](R 2.0)] osgi.wiring.package;
> (osgi.wiring.package=javax.annotation) Unresolved requirements:
> [[org.apache.sling.installer.core [2](R 2.0)] osgi.wiring.package;
> (osgi.wiring.package=javax.annotation)]
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:844){noformat}
> The interesting part here is that the {{javax.annotation}} classes that are
> required - for instance {{javax.annotation.CheckForNull}} are _not_ part of
> the JDK-provided {{javax.annotation}} package, they must come from another
> jar. In fact, we don't have that Jar deployed in the starter, but instead the
> JDK provides:
> {noformat}
> Generated.class
> PostConstruct.class
> PreDestroy.class
> Resource.class
> Resources.class
> {noformat}
> In a sense, this is very close to the root cause of SLING-7135 - solving one
> might solve both but the symptoms are very different so raising it separately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7235) Remove requirement for --add-modules java.se.ee
[
https://issues.apache.org/jira/browse/SLING-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7235.
--
> Remove requirement for --add-modules java.se.ee
> ---
>
> Key: SLING-7235
> URL: https://issues.apache.org/jira/browse/SLING-7235
> Project: Sling
> Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Labels: Sling-11-ReleaseNotes
> Fix For: Starter 11
>
>
> For now we are running Sling on Java 9 by adding {{-add-modules java.se.ee}}
> to the CLI arguments. We should remove this and make running Sling easier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7919) Duplicate feature name "sling-event" in sling-org-apache-sling-starter
[
https://issues.apache.org/jira/browse/SLING-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7919.
--
> Duplicate feature name "sling-event" in sling-org-apache-sling-starter
> --
>
> Key: SLING-7919
> URL: https://issues.apache.org/jira/browse/SLING-7919
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Starter 11
>
>
> The sling-discovery feature is named "sling-event" in the txt file:
> {code}
> $ grep "feature " src/main/provisioning/*.txt | grep event
> src/main/provisioning/sling-discovery.txt:[feature name=sling-event]
> src/main/provisioning/sling-event.txt:[feature name=sling-event]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7650) Update SCR, ConfigAdmin, Event Admin, Metatype and Http to R7 implementations
[ https://issues.apache.org/jira/browse/SLING-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7650. -- > Update SCR, ConfigAdmin, Event Admin, Metatype and Http to R7 implementations > - > > Key: SLING-7650 > URL: https://issues.apache.org/jira/browse/SLING-7650 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Labels: Sling-11-ReleaseNotes > Fix For: Starter 11 > > > The R7 implementations are released: > Apache Felix ConfigAdmin 1.9.0 > Apache Felix SCR 2.1.0 > Apache Felix Http Jetty 4.0.0 > Apache Felix Http Bridge 4.0.0 > Apache Felix Http Whiteboard 4.0.0 > Event Admin 1.5.0 > Metatype 1.2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7479) Add Sling Installer Health Check bundle to Sling Starter
[ https://issues.apache.org/jira/browse/SLING-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7479. -- > Add Sling Installer Health Check bundle to Sling Starter > > > Key: SLING-7479 > URL: https://issues.apache.org/jira/browse/SLING-7479 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Starter 10 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Starter 11 > > > The health check added via SLING-5888 is useful and therefore the according > bundle should be included in the Sling Starter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7565) Sling Composum shows error 500 on loading on Karaf and Starter
[ https://issues.apache.org/jira/browse/SLING-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7565. -- > Sling Composum shows error 500 on loading on Karaf and Starter > -- > > Key: SLING-7565 > URL: https://issues.apache.org/jira/browse/SLING-7565 > Project: Sling > Issue Type: Bug > Components: Karaf, Starter >Reporter: Purnendra Pratap Singh >Assignee: Oliver Lietz >Priority: Major > Fix For: Karaf Features 0.2.0, Starter 11 > > Attachments: Screen Shot 2018-03-30 at 3.06.35 PM.png > > > After installing Composum feature on Apache Karaf for Sling . > if I am trying to load /bin/browser.html first time I am seeing error 500 pop > up ( see screenshot attached for the error) and same error also comes > everytime we click on 'jcr:root' node on the Node Browser > > [Composum #128 - ClassCastException: java.lang.Integer cannot be cast to > java.lang.Long|https://github.com/ist-dresden/composum/issues/128] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8015) SmokeIT should use preemptive Basic Auth
[
https://issues.apache.org/jira/browse/SLING-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-8015.
--
> SmokeIT should use preemptive Basic Auth
>
>
> Key: SLING-8015
> URL: https://issues.apache.org/jira/browse/SLING-8015
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 11
>
>
> With the web console security provider 1.1.0 or newer a login form is
> presented when accessing {{/system/console}} without being logged in.
> This breaks the SmokeIT as it does not send basic auth credentials
> preemptively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-6130) Restrict access for principal everyone and move configuration to repoinit
[
https://issues.apache.org/jira/browse/SLING-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-6130.
--
> Restrict access for principal everyone and move configuration to repoinit
> -
>
> Key: SLING-6130
> URL: https://issues.apache.org/jira/browse/SLING-6130
> Project: Sling
> Issue Type: Improvement
> Components: JCR, Karaf, Launchpad, Oak
>Affects Versions: JCR Oak Server 1.1.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Labels: Sling-11-ReleaseNotes, security
> Fix For: JCR Oak Server 1.1.4, Karaf Integration Tests 0.2.0,
> Karaf Configs 0.2.0, Karaf Launchpad Integration Tests (Oak Tar) 0.0.2,
> Starter 11
>
> Attachments: error.log
>
>
> Currently {{everyone}} can {{read}} from {{/}} (configured in
> {{OakSlingRepositoryManager}}).
> Access for {{everyone}} should be restricted:
> * {{read}} should be restricted to {{/content}}
> * configuration of principals and ACLs should be done with _repoinit_
> # -Change path from {{/}} to {{/content}} in {{OakSlingRepositoryManager}}-
> (/) (-[r1764259|https://svn.apache.org/r1764259]-)
> # Fix modules (samples) relying on _unrestricted_ {{read}} access
> # Move configuration of ACLs to _repoinit_ (/)
> discussion on
> [dev@|https://lists.apache.org/thread.html/36908ed62ac93c63cad594a897f8abceb93f08da5bcea30dbce98e58@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7812) Update to Apache Felix Http Jetty 4.0.4, Configadmin 1.9.4 and SCR 2.1.2
[ https://issues.apache.org/jira/browse/SLING-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7812. -- > Update to Apache Felix Http Jetty 4.0.4, Configadmin 1.9.4 and SCR 2.1.2 > > > Key: SLING-7812 > URL: https://issues.apache.org/jira/browse/SLING-7812 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Starter 11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Move health checks to Felix
+1 - Andrei On Mon, Oct 22, 2018, 22:44 wrote: > +1 > > David Bosschaert > > On Mon, 22 Oct 2018 at 15:10, Georg Henzler wrote: > > > Hi all, > > > > to follow up on this conversation I would like to start a vote from > > Sling side to give green light for the move of Health Checks to Felix > > [1]. The Felix project has expressed interest [2]. > > > > Please vote to approve the move: > > > >[ ] +1 Approve the move > >[ ] 0 Don't care > >[ ] -1 I have concerns, in particular... > > > > This majority vote is open for at least 72 hours. > > > > -Georg > > > > [1] > > https://issues.apache.org/jira/browse/SLING-7980 > > https://issues.apache.org/jira/browse/FELIX-5952 > > > > [2] > > https://www.mail-archive.com/dev@felix.apache.org/msg46780.html > > > > > > On 2018-10-11 16:17, Georg Henzler wrote: > > > Hi Bertrand, > > > > > >> Maybe I missed something but I do not see agreement on a concrete plan > > >> here so IMO the move is premature. > > > > > > I had the feeling that there was an agreement that it is definitely > > > good to move the health checks to felix to make them available to a > > > larger audience, maybe there wasn't a clear agreement on how to do > > > this exactly yet, but I think we get closer to this. > > > > > >> 1) How do we keep compatibility so that Sling users can use the Felix > > >> HCs in the future... > > > > > > There is a clear path on how to migrate (replace api dependency and > > > search and replace over java import statements replacing sling.hc.api > > > with felix.hc.api). The version as attached to FELIX-5952 fully > > > supports the HC API as well without having it as dependency (see [1] > > > for details) - this means that all health checks that exist out there > > > work without change. However the next release of sling.hc.api should > > > deprecate it so everyone that upgrades gets the messages to use the > > > Felix API instead of the Sling API (I created [2] for it). > > > > > >> ... without ending up with two distinct projects each > > >> with their own smaller fractured community > > > > > > Deprecation of the Sling HC API and a clear migration path will not > > > fracture the community I believe... rather having the HC API in Felix > > > will allow all users/projects on the Felix platform to use it (e.g. > > > ServiceMix projects) > > > > > >> 2) How can Sling committers maintain the module once it moves to > > >> Felix, is the Felix PMC open to give us write access to it? > > > > > > I think the Felix community is open to invite people for it [3] > > > > > >> 3) What's the plan w.rt. merging with the systemready module > > > > > > I agree with Christian here [4] that systemready can be implemented as > > > health check (once some minor improvements have been made to the > > > current API) > > > > > >> Before this is defined and agreed upon, I think a move is premature > > >> and likely to end up with two distinct modules and communities. > > > > > > I really want to avoid this as well! > > > > > > -Georg > > > > > > > > > [1] > > > > > > https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281 > > > [2] https://issues.apache.org/jira/browse/SLING-7980 > > > [3] > > > > > > https://lists.apache.org/thread.html/974b95a91e3d4f2e5ba3aec1f04a85eb2adf65d80e24ea78287284af@%3Cdev.felix.apache.org%3E > > > > > > [4] > > > From > > > > > > https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E > > > > > >> As sling hc is a lot more mature and battle proven I can imagine to > > >> move to > > >> this basic framework and change the system ready checks to this API. > > >
[RESULT][VOTE] Release Apache Sling 11
Hi, The vote has passed with the following result : +1 (binding): Carsten Ziegeler, Daniel Klco, Karl Pauls, Radu Cotescu, Georg Henzler, Oliver Lietz, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Thanks all for voting, Robert
