[jira] [Created] (SLING-4946) Model dependencies are not followed transitively
Carsten Ziegeler created SLING-4946: --- Summary: Model dependencies are not followed transitively Key: SLING-4946 URL: https://issues.apache.org/jira/browse/SLING-4946 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0, Slingstart Maven Plugin 1.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 If model c depends on model b and model b depends on model a, when building c, the reference from b to a will not be handled, either resulting in a build failure or missing artifacts -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4951) Make query for validation models more Oak-friendly
[
https://issues.apache.org/jira/browse/SLING-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696992#comment-14696992
]
Justin Edelson commented on SLING-4951:
---
My assumption (which is perhaps incorrect) is that any usage of Sling on Oak is
going to have *at minimum* an index on the sling:resourceType property.
Make query for validation models more Oak-friendly
--
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some
path HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource
type' /* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type] */, path=/apps//*);
consider creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4951) Make query for validation models more Oak-friendly
[
https://issues.apache.org/jira/browse/SLING-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696995#comment-14696995
]
Konrad Windszus commented on SLING-4951:
That is correct but still my 2 points from above stay valid, because
{{validatedResourceType}} will not be indexed by default nor the node name.
Make query for validation models more Oak-friendly
--
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some
path HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource
type' /* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type] */, path=/apps//*);
consider creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4951) Make query for validation models more Oak-friendly
[
https://issues.apache.org/jira/browse/SLING-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697010#comment-14697010
]
Justin Edelson commented on SLING-4951:
---
I agree that a validatedResourceType index would be helpful. I'm not sure I
understand your point about node name. There's no node name in the query above.
Make query for validation models more Oak-friendly
--
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some
path HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource
type' /* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type] */, path=/apps//*);
consider creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4947) Update to latest Apache Felix Metatype 1.1.2
Carsten Ziegeler created SLING-4947: --- Summary: Update to latest Apache Felix Metatype 1.1.2 Key: SLING-4947 URL: https://issues.apache.org/jira/browse/SLING-4947 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4948) Update to latest Apache Felix ConfigAdmin 1.8.8
[ https://issues.apache.org/jira/browse/SLING-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4948. - Resolution: Fixed Updated in rev 1695846 Update to latest Apache Felix ConfigAdmin 1.8.8 --- Key: SLING-4948 URL: https://issues.apache.org/jira/browse/SLING-4948 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4950) Update to Apache Felix SCR 2.0.0
Carsten Ziegeler created SLING-4950: --- Summary: Update to Apache Felix SCR 2.0.0 Key: SLING-4950 URL: https://issues.apache.org/jira/browse/SLING-4950 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4949) Update to latest Apache Felix Event Admin 1.4.4
[ https://issues.apache.org/jira/browse/SLING-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696750#comment-14696750 ] Carsten Ziegeler commented on SLING-4949: - Updated in rev 1695847 Update to latest Apache Felix Event Admin 1.4.4 --- Key: SLING-4949 URL: https://issues.apache.org/jira/browse/SLING-4949 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4949) Update to latest Apache Felix Event Admin 1.4.4
[ https://issues.apache.org/jira/browse/SLING-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4949. - Resolution: Fixed Update to latest Apache Felix Event Admin 1.4.4 --- Key: SLING-4949 URL: https://issues.apache.org/jira/browse/SLING-4949 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4949) Update to latest Apache Felix Event Admin 1.4.4
Carsten Ziegeler created SLING-4949: --- Summary: Update to latest Apache Felix Event Admin 1.4.4 Key: SLING-4949 URL: https://issues.apache.org/jira/browse/SLING-4949 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Health Check IT Test Failing
On Fri, Aug 14, 2015 at 10:14 AM, Carsten Ziegeler cziege...@apache.org wrote: it seems all the HC it tests are failing now indeed - fixed in revision 1695834, sorry I forgot to add some dependencies after committing the new HC servlet. -Bertrand
[jira] [Resolved] (SLING-4946) Model dependencies are not followed transitively
[ https://issues.apache.org/jira/browse/SLING-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4946. - Resolution: Fixed Fixed in rev 1695835 by traversing down all model files Model dependencies are not followed transitively Key: SLING-4946 URL: https://issues.apache.org/jira/browse/SLING-4946 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.2.0, Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 If model c depends on model b and model b depends on model a, when building c, the reference from b to a will not be handled, either resulting in a build failure or missing artifacts -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4945) Model files are missing from created repository
[ https://issues.apache.org/jira/browse/SLING-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4945. - Resolution: Fixed Fixed in rev 1695835 by keeping the dependency models in the project and writing them out when the mojo is invoked Model files are missing from created repository --- Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 The repository goal is creating a repository of all referenced artifacts. The model of the project and all referenced model files are missing - the artifacts from those models are added -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.3.2
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Sling Slingstart Maven Plugin 1.3.2
Hi, We solved 2 issues in this release https://issues.apache.org/jira/browse/SLING/fixforversion/12333104 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1314/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1314 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-4948) Update to latest Apache Felix ConfigAdmin 1.8.8
Carsten Ziegeler created SLING-4948: --- Summary: Update to latest Apache Felix ConfigAdmin 1.8.8 Key: SLING-4948 URL: https://issues.apache.org/jira/browse/SLING-4948 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4947) Update to latest Apache Felix Metatype 1.1.2
[ https://issues.apache.org/jira/browse/SLING-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4947. - Resolution: Fixed Updated in 1695845 Update to latest Apache Felix Metatype 1.1.2 Key: SLING-4947 URL: https://issues.apache.org/jira/browse/SLING-4947 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4950) Update to Apache Felix SCR 2.0.0
[ https://issues.apache.org/jira/browse/SLING-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4950. - Resolution: Fixed Updated in rev 1695848 Update to Apache Felix SCR 2.0.0 Key: SLING-4950 URL: https://issues.apache.org/jira/browse/SLING-4950 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Health Check IT Test Failing
it seems all the HC it tests are failing now Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4951) Make query for validation models more Oak-friendly
[
https://issues.apache.org/jira/browse/SLING-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697087#comment-14697087
]
Konrad Windszus commented on SLING-4951:
You see it in the translation to the SQL2 query that the part
{{/jcr:root/apps//validation}} of the XPath query is translated into an inner
join. The first part /jcr:root/apps becomes {{isdescendantnode('/apps)}} the
second part becomes {{name(a)=validation}}.
Make query for validation models more Oak-friendly
--
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some
path HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource
type' /* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type] */, path=/apps//*);
consider creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4952) Provide option to dump Java code from Sightly Compiler
Konrad Windszus created SLING-4952:
--
Summary: Provide option to dump Java code from Sightly Compiler
Key: SLING-4952
URL: https://issues.apache.org/jira/browse/SLING-4952
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Konrad Windszus
Currently only the compiled servlets are given out through the
{{org.apache.sling.commons.fsclassloader}}. The Java sources should be given
out in addition similar what the
{{org.apache.sling.scripting.jsp.JspScriptEngineFactory}} does via
{{jasper.keepgenerated}}. Could you add an option to persist the Java sources
somewhere. That would ease debugging a lot!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4952) Provide option to dump Java code from Sightly Compiler
[
https://issues.apache.org/jira/browse/SLING-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-4952.
-
Resolution: Duplicate
Provide option to dump Java code from Sightly Compiler
--
Key: SLING-4952
URL: https://issues.apache.org/jira/browse/SLING-4952
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Konrad Windszus
Currently only the compiled servlets are given out through the
{{org.apache.sling.commons.fsclassloader}}. The Java sources should be given
out in addition similar what the
{{org.apache.sling.scripting.jsp.JspScriptEngineFactory}} does via
{{jasper.keepgenerated}}. Could you add an option to persist the Java sources
somewhere. That would ease debugging a lot!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4952) Provide option to dump Java code from Sightly Compiler
[
https://issues.apache.org/jira/browse/SLING-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697227#comment-14697227
]
Radu Cotescu commented on SLING-4952:
-
This can already be done by providing the following configuration:
{noformat}
org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration
org.apache.sling.scripting.sightly.devmode=Btrue
{noformat}
Provide option to dump Java code from Sightly Compiler
--
Key: SLING-4952
URL: https://issues.apache.org/jira/browse/SLING-4952
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Konrad Windszus
Currently only the compiled servlets are given out through the
{{org.apache.sling.commons.fsclassloader}}. The Java sources should be given
out in addition similar what the
{{org.apache.sling.scripting.jsp.JspScriptEngineFactory}} does via
{{jasper.keepgenerated}}. Could you add an option to persist the Java sources
somewhere. That would ease debugging a lot!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4693) Write Sightly generated classes' source code to disk when the scripting engine is in dev mode
[
https://issues.apache.org/jira/browse/SLING-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697400#comment-14697400
]
Konrad Windszus commented on SLING-4693:
To make this feature a littlebit more visible, it would be great to extend the
description of Development Mode at
https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/SightlyEngineConfiguration.java#L49.
Write Sightly generated classes' source code to disk when the scripting
engine is in dev mode
-
Key: SLING-4693
URL: https://issues.apache.org/jira/browse/SLING-4693
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.4
Previous to SLING-4692 generated Java classes' source were available in the
repository. However, the current implementation doesn't write the source code
anywhere any more.
The source code should be written using the default {{ClassLoaderWriter}} to
its default root, but only when the Sightly scripting engine has its dev mode
enabled - see the
{{org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration}}
OSGi configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697315#comment-14697315 ] Carsten Ziegeler commented on SLING-4676: - [~baedke] I'm confused :) Isn't your patch already doing all that is required? As far as i can tell setting allowCoreThreadTimeOut to true and settings the keep alive time should do it. Or do I overlook something? Clean up threads or refresh threads when put back into the pool --- Key: SLING-4676 URL: https://issues.apache.org/jira/browse/SLING-4676 Project: Sling Issue Type: Improvement Components: Commons Reporter: Carsten Ziegeler Fix For: Commons Threads 3.2.2 Attachments: sling-4676-provisional.patch A thread from the pool might use thread locals which are - for whatever reason - not cleaned up, when the thread is put back into the pool. This can lead to memory leaks. We should protect against this. Unfortunately there is no official API to clean up thread locals. There are solutions out there using reflection. Another option is to simply discard the thread object after some time of usage and use a fresh one. This needs to include thread objects staying in the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4806) Only invalidate those DynamicClassLoaderManagers which are becoming invalid
[
https://issues.apache.org/jira/browse/SLING-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4806:
---
Description:
Currently all {{DynamicClassLoaderManagers}} become invalid if
# a new bundle has been started which provides packages which have been
previously unresolvable by any of the {{DynamicClassLoader}} s or if
# a bundle is no longer active which used to provide at least one class being
loaded through one of the {{DynamicClassLoader}} s.
In that case the {{DynamicClassLoaderManagerFactory}} is first unregistered and
then reregistered
(https://github.com/apache/sling/blob/trunk/bundles/commons/classloader/src/main/java/org/apache/sling/commons/classloader/impl/Activator.java#L134)
The whole refresh logic is IMHO only necessary because the JRE caches all
classes being requested through a classloader.
The invalidation could be improved by only reregistering those
{{DynamicClassLoaderManagers}} which have been used to
# load a class which was not available in the past but may be now available
(due to a new bundle)
# load a class which was provided through a bundle which is now no longer being
available
was:
Currently all {{DynamicClassLoaderManagers}} become invalid if
# a new bundle has been started which provides packages which have been
previously unresolvable by any of the {{DynamicClassLoader}}s or if
# a bundle is no longer active which used to provide at least one class being
loaded through one of the {{DynamicClassLoader}}s.
In that case the {{DynamicClassLoaderManagerFactory}} is first unregistered and
then reregistered
(https://github.com/apache/sling/blob/trunk/bundles/commons/classloader/src/main/java/org/apache/sling/commons/classloader/impl/Activator.java#L134)
The whole refresh logic is IMHO only necessary because the JRE caches all
classes being requested through a classloader.
The invalidation could be improved by only reregistering those
{{DynamicClassLoaderManagers}} which have been used to
# load a class which was not available in the past but may be now available
(due to a new bundle)
# load a class which was provided through a bundle which is now no longer being
available
Only invalidate those DynamicClassLoaderManagers which are becoming invalid
---
Key: SLING-4806
URL: https://issues.apache.org/jira/browse/SLING-4806
Project: Sling
Issue Type: Improvement
Components: Commons
Affects Versions: Commons ClassLoader 1.3.2
Reporter: Konrad Windszus
Attachments: SLING-4806-notworking.patch
Currently all {{DynamicClassLoaderManagers}} become invalid if
# a new bundle has been started which provides packages which have been
previously unresolvable by any of the {{DynamicClassLoader}} s or if
# a bundle is no longer active which used to provide at least one class being
loaded through one of the {{DynamicClassLoader}} s.
In that case the {{DynamicClassLoaderManagerFactory}} is first unregistered
and then reregistered
(https://github.com/apache/sling/blob/trunk/bundles/commons/classloader/src/main/java/org/apache/sling/commons/classloader/impl/Activator.java#L134)
The whole refresh logic is IMHO only necessary because the JRE caches all
classes being requested through a classloader.
The invalidation could be improved by only reregistering those
{{DynamicClassLoaderManagers}} which have been used to
# load a class which was not available in the past but may be now available
(due to a new bundle)
# load a class which was provided through a bundle which is now no longer
being available
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4951) Make query for validation models more Oak-friendly
Konrad Windszus created SLING-4951:
--
Summary: Make query for validation models more Oak-friendly
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some path
HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource type'
/* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model and
@validatedResourceType=some resource type] */, path=/apps//*); consider
creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4951) Make query for validation models more Oak-friendly
[
https://issues.apache.org/jira/browse/SLING-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696939#comment-14696939
]
Konrad Windszus commented on SLING-4951:
The warning is caused by the facts
# that Oak (or better Sling with Oak) does not have a property index for
{{validatedResourceType}}
# that Oak does not yet support a query considering node names:
https://issues.apache.org/jira/browse/OAK-1752
Make query for validation models more Oak-friendly
--
Key: SLING-4951
URL: https://issues.apache.org/jira/browse/SLING-4951
Project: Sling
Issue Type: Improvement
Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Validation 1.0.0
Currently the {{ResourceValidationModelProviderImpl}} is looking for
appropriate models with the following query:
{{/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type}}
This leads to warnings like this in OAK:
{code}
14.08.2015 14:07:04.659 *WARN* [0:0:0:0:0:0:0:1 [1439554021017] GET some
path HTTP/1.1] org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor
Traversed 8000 nodes with filter Filter(query=select b.[jcr:path] as
[jcr:path], b.[jcr:score] as [jcr:score], b.* from [nt:base] as a inner join
[nt:base] as b on isdescendantnode(b, a) where name(a) = 'validation' and
isdescendantnode(a, '/apps') and b.[sling:resourceType] =
'sling/validation/model' and b.[validatedResourceType] = 'some resource
type' /* xpath:
/jcr:root/apps//validation//*[@sling:resourceType=sling/validation/model
and @validatedResourceType=some resource type] */, path=/apps//*);
consider creating an index or changing the query
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Sightly warnings by GlobalShadowChecker
In our code I see a lot of warnings like this one: org.apache.sling.scripting.sightly.impl.compiler.util.GlobalShadowChecker Global variable 'component' is being overridden in template It seems that the Sightly compiler always emits that warning in case a global variable name has been newly defined in a Sightly script like this sly data-sly-use.someGlobalVariableName=“someClass”…/sly While I do understand that this might lead to issues, I would rather make that GlobalShadowChecker functionality configurable. This is especially useful as previous versions of the Sightly compiler didn’t have that feature. WDYT? Konrad
