[jira] Created: (SLING-1939) wrong character encoding for compiled JSP scripts

2011-01-19 Thread Victor Saar (JIRA)
wrong character encoding for compiled JSP scripts
-

 Key: SLING-1939
 URL: https://issues.apache.org/jira/browse/SLING-1939
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting JSP 2.0.12
Reporter: Victor Saar
Priority: Minor


I have a JSP that contains some static text with special chars (e.g. umlauts). 
Though the JSP itself seems to be correctly encoded as UTF-8, the compiled 
.java class under /var/classes/... shows these characters wrongly encoded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-1939) wrong character encoding for compiled JSP scripts

2011-02-21 Thread Victor Saar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Saar updated SLING-1939:
---

Attachment: html.jsp

Here's a sample JSP and it couldn't be any simpler. Julian's suggestion 
workaround helps indeed.

> wrong character encoding for compiled JSP scripts
> -
>
> Key: SLING-1939
> URL: https://issues.apache.org/jira/browse/SLING-1939
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.12
>Reporter: Victor Saar
>Priority: Minor
> Attachments: html.jsp
>
>
> I have a JSP that contains some static text with special chars (e.g. 
> umlauts). Though the JSP itself seems to be correctly encoded as UTF-8, the 
> compiled .java class under /var/classes/... shows these characters wrongly 
> encoded.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SLING-1939) wrong character encoding for compiled JSP scripts

2011-02-21 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997344#comment-12997344
 ] 

Victor Saar commented on SLING-1939:


Okay, that makes totally sense and thanks for clarifying. Setting the page 
encoding explicitly is not a big deal anyways.

> wrong character encoding for compiled JSP scripts
> -
>
> Key: SLING-1939
> URL: https://issues.apache.org/jira/browse/SLING-1939
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.12
>Reporter: Victor Saar
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: html.jsp
>
>
> I have a JSP that contains some static text with special chars (e.g. 
> umlauts). Though the JSP itself seems to be correctly encoded as UTF-8, the 
> compiled .java class under /var/classes/... shows these characters wrongly 
> encoded.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (SLING-2195) Add a resource visitor

2011-08-26 Thread Victor Saar (JIRA)
Add a resource visitor
--

 Key: SLING-2195
 URL: https://issues.apache.org/jira/browse/SLING-2195
 Project: Sling
  Issue Type: New Feature
  Components: API
Reporter: Victor Saar
Priority: Minor


It would be nice to have a resource visitor abstract base class that helps in 
traversing a resource tree and do some actual work on the individual resources.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (SLING-2195) Add a resource visitor

2011-08-26 Thread Victor Saar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Saar updated SLING-2195:
---

Attachment: SLING-2195.patch

Proposed patch for review.

> Add a resource visitor
> --
>
> Key: SLING-2195
> URL: https://issues.apache.org/jira/browse/SLING-2195
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>Reporter: Victor Saar
>Priority: Minor
> Attachments: SLING-2195.patch
>
>
> It would be nice to have a resource visitor abstract base class that helps in 
> traversing a resource tree and do some actual work on the individual 
> resources.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (SLING-2195) Add a resource visitor

2012-10-24 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483097#comment-13483097
 ] 

Victor Saar commented on SLING-2195:


Thanks Carsten, great to have that in eventually.

> Add a resource visitor
> --
>
> Key: SLING-2195
> URL: https://issues.apache.org/jira/browse/SLING-2195
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>Reporter: Victor Saar
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: API 2.2.6
>
> Attachments: SLING-2195.patch
>
>
> It would be nice to have a resource visitor abstract base class that helps in 
> traversing a resource tree and do some actual work on the individual 
> resources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (SLING-10427) Pipeline executed on error even though processError=false

2021-05-27 Thread Victor Saar (Jira)
Victor Saar created SLING-10427:
---

 Summary: Pipeline executed on error even though processError=false
 Key: SLING-10427
 URL: https://issues.apache.org/jira/browse/SLING-10427
 Project: Sling
  Issue Type: Bug
Affects Versions: Rewriter 1.2.2
Reporter: Victor Saar


I have a transformer configured in a custom pipeline that can throw an 
exception in its {{init}} method. Even though the pipeline is configured to not 
process errors, i.e. {{processError=false}}, it's still executed and fails 
again resulting in the error page not shown.

In addition to the {{processError}} setting, 
{{ProcessorConfigurationImpl#match}} checks if a 
{{javax.servlet.error.status_code}} request attribute is set, which is not the 
case.

I see that the {{SlingRequestProcessorImpl}} catches the exception and sets a 
{{javax.servlet.error.servlet_name}} request attribute before initiating the 
error handler, but not the one for status code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-3028) Support for progress tracking of jobs

2013-08-28 Thread Victor Saar (JIRA)
Victor Saar created SLING-3028:
--

 Summary: Support for progress tracking of jobs
 Key: SLING-3028
 URL: https://issues.apache.org/jira/browse/SLING-3028
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Victor Saar


For long-running jobs, it would be useful to have some means to track progress, 
which can be shown in a console for the user. This should include the following:

* ETA
* Completeness value computed from (optional, defaults to 1.0) max and current 
value (e.g. 42% or 23/100)
* Log output stream for detailed progress information
* Failure reason in case job failed

AFAICS this requires a few changes to the existing implementation:

* Jobs need additional support for setting properties, e.g. max and current 
progress value
* Jobs need to be kept at least for a while after they completed/failed to give 
access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (SLING-3028) Support for progress tracking of jobs

2013-08-29 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753471#comment-13753471
 ] 

Victor Saar commented on SLING-3028:


I agree that making this a queue configuration doesn't feel right. In general, 
I would see the following jobs as worth keeping:

* Jobs that failed
* Jobs that wrote to the log stream

Alternatively, we could make it a property of the job. So a job itself would 
decide if it's worthwhile to keep the information any longer. I can imagine 
situations where it makes sense to do that even for successful jobs. In the 
end, the job implementation knows best what situations that would be, right?

How long jobs are kept that we actually need to keep, could still be a 
configuration property of the queue. Or it becomes global property of the job 
engine (which a queue may be able to overwrite).

> Support for progress tracking of jobs
> -
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>  Labels: jobs
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (SLING-3028) Support for progress tracking of jobs

2013-09-03 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756607#comment-13756607
 ] 

Victor Saar commented on SLING-3028:


bq. I have the tendency to keep failed jobs forever - but have an API to retry 
or remove them. A scheduled configuration might always lead to the problem that 
failed jobs are removed before someone took an action.

+1

But still, as Jeff and I mentioned already, it would be useful to keep jobs 
even if they succeeded. Having to come up with something else for that scenario 
(e.g. a separate log) kind of defeats the purpose of this whole issue;).

> Support for progress tracking of jobs
> -
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>  Labels: jobs
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (SLING-3028) Support for progress tracking of jobs

2013-09-05 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759017#comment-13759017
 ] 

Victor Saar commented on SLING-3028:


bq. Just a first quick draft

API draft looks generally good, but a few comments:

* Providing ETA on {{start()}} seems weird, as you usually only know it after 
doing at least some work, and you usually update it continuously. I'd rather 
add a separate {{setEta()}} method or update it when setting progress.
* What's the semantic when not providing an ETA? Will the job engine compute 
one itself (if yes, using a naive approach would certainly be enough)?
* For log output, how about providing a buffered {{Writer}} instead, which 
allows jobs to use a {{PrintWriter}} for example

bq. Could it be that a "successful" job wants to report some output as well, 
because it failed partially or produced warnings, that did not make it fail for 
the job manager?

I definitely see use cases like that. We could introduce a new 
{{JobState.OK_WITH_WARNINGS}} for example that isn't failed for the job engine, 
but kept for further investigation. But we could also just use the queue 
configuration Carsten suggested, which is more flexible. And you usually know 
what kind of jobs can exhibit such behavior.

> Support for progress tracking of jobs
> -
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>  Labels: jobs
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (SLING-3028) Support for progress tracking of jobs

2013-09-06 Thread Victor Saar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Saar updated SLING-3028:
---

Attachment: SLING-3028.patch

I think the biggest issue of the current version is, that ETA and steps are 
mutually exclusive, which is usually not the case. The process needs to carry 
out a certain number of steps, which will take a certain time (ETA).

I've attached a patch with a single {{startProgress()}} method, {{setSteps()}} 
for setting the total number of steps, and {{setProgress()}} and {{setETA()}} 
for setting the current step and ETA.

> Support for progress tracking of jobs
> -
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>  Labels: jobs
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (SLING-3028) Support for progress tracking of jobs

2013-09-09 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13761721#comment-13761721
 ] 

Victor Saar commented on SLING-3028:


bq. If I understand you correctly, you say that you have an ETA for each step, 
right?

No, that's not what I meant. I just wanted to say that it may make sense to 
provide both, steps and an ETA, but just an ETA for the whole process and not 
for each step. Let's say you have a 3-step process and you know that the last 
two steps roughly take twice the time of the first one. Then you could set 
steps to three, and you could set the ETA to 5 times the processing time of the 
first step. Your current draft doesn't allow you to do that, right?

> Support for progress tracking of jobs
> -
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>  Labels: jobs
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (SLING-3103) Groovy extemsions for dealing with JCR and Spock

2013-09-24 Thread Victor Saar (JIRA)
Victor Saar created SLING-3103:
--

 Summary: Groovy extemsions for dealing with JCR and Spock
 Key: SLING-3103
 URL: https://issues.apache.org/jira/browse/SLING-3103
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Victor Saar


A while ago I wrote a set of Groovy extensions aimed at making it easier to 
work with JCR. The main use case for this is probably testing and it includes 
an extension for the Spock testing framework, as well. But it could certainly 
be used for non-testing code.

I think that Sling would be a good place for these extensions to live in. They 
are not particularly tied to Sling, but could be further extended to the 
Resource API for example.

I'll attach a patch and some documentation so that people can get an idea of 
what's covered. (The patch currently adds a separate groovy artifact in 
contrib/extensions/groovy, because I didn't know where to put it else. I just 
realized that there is a Groovy extension bundle already, so it could certainly 
be added there.)

I'm looking forward to feedback.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (SLING-3103) Groovy extemsions for dealing with JCR and Spock

2013-09-24 Thread Victor Saar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Saar updated SLING-3103:
---

Attachment: sling-groovy-extensions.pdf

Attach documentation.

> Groovy extemsions for dealing with JCR and Spock
> 
>
> Key: SLING-3103
> URL: https://issues.apache.org/jira/browse/SLING-3103
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
> Attachments: sling-groovy-extensions.pdf
>
>
> A while ago I wrote a set of Groovy extensions aimed at making it easier to 
> work with JCR. The main use case for this is probably testing and it includes 
> an extension for the Spock testing framework, as well. But it could certainly 
> be used for non-testing code.
> I think that Sling would be a good place for these extensions to live in. 
> They are not particularly tied to Sling, but could be further extended to the 
> Resource API for example.
> I'll attach a patch and some documentation so that people can get an idea of 
> what's covered. (The patch currently adds a separate groovy artifact in 
> contrib/extensions/groovy, because I didn't know where to put it else. I just 
> realized that there is a Groovy extension bundle already, so it could 
> certainly be added there.)
> I'm looking forward to feedback.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (SLING-3103) Groovy extemsions for dealing with JCR and Spock

2013-09-24 Thread Victor Saar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Saar updated SLING-3103:
---

Attachment: SLING-3103.patch

Attach patch adding Groovy extension artifact.

> Groovy extemsions for dealing with JCR and Spock
> 
>
> Key: SLING-3103
> URL: https://issues.apache.org/jira/browse/SLING-3103
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
> Attachments: SLING-3103.patch, sling-groovy-extensions.pdf
>
>
> A while ago I wrote a set of Groovy extensions aimed at making it easier to 
> work with JCR. The main use case for this is probably testing and it includes 
> an extension for the Spock testing framework, as well. But it could certainly 
> be used for non-testing code.
> I think that Sling would be a good place for these extensions to live in. 
> They are not particularly tied to Sling, but could be further extended to the 
> Resource API for example.
> I'll attach a patch and some documentation so that people can get an idea of 
> what's covered. (The patch currently adds a separate groovy artifact in 
> contrib/extensions/groovy, because I didn't know where to put it else. I just 
> realized that there is a Groovy extension bundle already, so it could 
> certainly be added there.)
> I'm looking forward to feedback.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (SLING-3028) Support for progress tracking of jobs and keeping jobs

2013-10-09 Thread Victor Saar (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790327#comment-13790327
 ] 

Victor Saar commented on SLING-3028:


I have no deep knowledge of the job processing bundle, but the changes 
generally look good to me. If the progress tracking API is missing anything 
will become apparent when people start using it.

> Support for progress tracking of jobs and keeping jobs
> --
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>Assignee: Carsten Ziegeler
>  Labels: jobs
> Fix For: Extensions Event 3.3.0
>
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream



--
This message was sent by Atlassian JIRA
(v6.1#6144)