[jira] [Updated] (SLING-8574) Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider
[ https://issues.apache.org/jira/browse/SLING-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-8574: - Description: While analyzing excessive memory usage in an AEM 6.4 instance I discovered a memory leak transitively introduced via the SlyBindingsValues Provider. Here, a configurable list of JavaScripts is run to produce factory functions. These functions are retained in an application-scoped map in order to be injected into the bindings of future script executions. Here, the SlyBindingsValuesProvider creates these factory function instances by executing the factory scripts using, amongst others, the current ENGINE-scoped script bindings. The resulting compiled JS representations reference a org.mozilla.javascript.NativeCall instance, which is referencing a org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel instance has a slots[] array member who's Slot instances point to org.mozilla.javascript.NativeJavaObject instances representing at least all objects present in the bindings during the factory script execution. Thus, a chain of strong references is formed to request-scoped instances. This keeps open dozens to potentially thousands of request-scoped Objects such as Sling Models, requests, resources, resource resolvers and their respective transitive hull, resulting in significant memory consumption. I have attached an excerpt of the respective view on the Heap generated using JProfiler. Note that the issue is not specific to the aem.js mentioned therein, but is generally caused by any of the factory scripts. was: While analyzing excessive memory usage in an AEM 6.4 instance I discovered a memory leak transitively introduced via the SlyBindingsValues Provider. Here, a configurable list of JavaScripts is run to produce factory functions. These functions are retained in an application-scoped map in order to be injected into the bindings of future script executions. Here, the SlyBindingsValuesProvider creates these factory function instances by executing the factory scripts using, amongst others, the current ENGINE-scoped script bindings. The resulting compiled JS representations reference a org.mozilla.javascript.NativeCall instance, which is referencing a org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel instance has a slots[] array member who's Slot instances point to org.mozilla.javascript.NativeJavaObject instances representing at least all objects present in the bindings during the factory script execution. Thus, a chain of strong references is formed to request-scoped instances. This keeps open dozens to potentially thousands of request-scoped Objects such as Sling Models, requests, resources, resource resolvers and their respective transitive hull, resulting in significant memory consumption. I have attached an excerpt of the respective view on the Heap generated using JProfiler. > Memory leak via cached JavaScript factory functions in > SlyBindingsValuesProvider > > > Key: SLING-8574 > URL: https://issues.apache.org/jira/browse/SLING-8574 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL JS Use Provider 1.0.28 >Reporter: Olaf Otto >Priority: Critical > Labels: memory, memory-leak > Attachments: Heap_walker_Reference_Graph.html > > > While analyzing excessive memory usage in an AEM 6.4 instance I discovered a > memory leak transitively introduced via the SlyBindingsValues Provider. > Here, a configurable list of JavaScripts is run to produce factory functions. > These functions are retained in an application-scoped map in order to be > injected into the bindings of future script executions. > Here, the SlyBindingsValuesProvider creates these factory function instances > by executing the factory scripts using, amongst others, the current > ENGINE-scoped script bindings. > The resulting compiled JS representations reference a > org.mozilla.javascript.NativeCall instance, which is referencing a > org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel > instance has a slots[] array member who's Slot instances point to > org.mozilla.javascript.NativeJavaObject instances representing at least all > objects present in the bindings during the factory script execution. > Thus, a chain of strong references is formed to request-scoped instances. > This keeps open dozens to potentially thousands of request-scoped Objects > such as Sling Models, requests, resources, resource resolvers and their > respective transitive hull, resulting in significant memory consumption. > > I have attached an excerpt of the respective view on the Heap generated using > JProfiler.
[jira] [Created] (SLING-8574) Memory leak fia cached JavaScript facotry functions in SlyBindingsValuesProvider
Olaf Otto created SLING-8574: Summary: Memory leak fia cached JavaScript facotry functions in SlyBindingsValuesProvider Key: SLING-8574 URL: https://issues.apache.org/jira/browse/SLING-8574 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting HTL JS Use Provider 1.0.28 Reporter: Olaf Otto Attachments: Heap_walker_Reference_Graph.html While analyzing excessive memory usage in an AEM 6.4 instance I discovered a memory leak transitively introduced via the SlyBindingsValues Provider. Here, a configurable list of JavaScripts is run to produce factory functions. These functions are retained in an application-scoped map in order to be injected into the bindings of future script executions. Here, the SlyBindingsValuesProvider creates these factory function instances by executing the factory scripts using, amongst others, the current ENGINE-scoped script bindings. The resulting compiled JS representations reference a org.mozilla.javascript.NativeCall instance, which is referencing a org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel instance has a slots[] array member who's Slot instances point to org.mozilla.javascript.NativeJavaObject instances representing at least all objects present in the bindings during the factory script execution. Thus, a chain of strong references is formed to request-scoped instances. This keeps open dozens to potentially thousands of request-scoped Objects such as Sling Models, requests, resources, resource resolvers and their respective transitive hull, resulting in significant memory consumption. I have attached an excerpt of the respective view on the Heap generated using JProfiler. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SLING-8574) Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider
[ https://issues.apache.org/jira/browse/SLING-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-8574: - Summary: Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider (was: Memory leak fia cached JavaScript facotry functions in SlyBindingsValuesProvider) > Memory leak via cached JavaScript factory functions in > SlyBindingsValuesProvider > > > Key: SLING-8574 > URL: https://issues.apache.org/jira/browse/SLING-8574 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL JS Use Provider 1.0.28 >Reporter: Olaf Otto >Priority: Critical > Labels: memory, memory-leak > Attachments: Heap_walker_Reference_Graph.html > > > While analyzing excessive memory usage in an AEM 6.4 instance I discovered a > memory leak transitively introduced via the SlyBindingsValues Provider. > Here, a configurable list of JavaScripts is run to produce factory functions. > These functions are retained in an application-scoped map in order to be > injected into the bindings of future script executions. > Here, the SlyBindingsValuesProvider creates these factory function instances > by executing the factory scripts using, amongst others, the current > ENGINE-scoped script bindings. > The resulting compiled JS representations reference a > org.mozilla.javascript.NativeCall instance, which is referencing a > org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel > instance has a slots[] array member who's Slot instances point to > org.mozilla.javascript.NativeJavaObject instances representing at least all > objects present in the bindings during the factory script execution. > Thus, a chain of strong references is formed to request-scoped instances. > This keeps open dozens to potentially thousands of request-scoped Objects > such as Sling Models, requests, resources, resource resolvers and their > respective transitive hull, resulting in significant memory consumption. > > I have attached an excerpt of the respective view on the Heap generated using > JProfiler. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SLING-7781) LogoutServlet does not "sing.servlet.paths" as an array
Olaf Otto created SLING-7781:
Summary: LogoutServlet does not "sing.servlet.paths" as an array
Key: SLING-7781
URL: https://issues.apache.org/jira/browse/SLING-7781
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.4.2
Reporter: Olaf Otto
The org.apache.sling.auth.core.impl.LogoutServlet defines the
sling.servlet.paths without a cardinality, thus the respective configuration
dialog does not allow specifying multiple entries. It should be like so:
{code:java}
/**
* The servlet is registered on this path.
*/
@Property(name = "sling.servlet.paths", cardinality=Integer.MAX_VALUE)
public static final String SERVLET_PATH = "/system/sling/logout";
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7781) LogoutServlet does not define "sing.servlet.paths" as an array
[
https://issues.apache.org/jira/browse/SLING-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Otto updated SLING-7781:
-
Summary: LogoutServlet does not define "sing.servlet.paths" as an array
(was: LogoutServlet does not "sing.servlet.paths" as an array)
> LogoutServlet does not define "sing.servlet.paths" as an array
> --
>
> Key: SLING-7781
> URL: https://issues.apache.org/jira/browse/SLING-7781
> Project: Sling
> Issue Type: Bug
> Components: Authentication
>Affects Versions: Auth Core 1.4.2
>Reporter: Olaf Otto
>Priority: Minor
>
> The org.apache.sling.auth.core.impl.LogoutServlet defines the
> sling.servlet.paths without a cardinality, thus the respective configuration
> dialog does not allow specifying multiple entries. It should be like so:
> {code:java}
>/**
> * The servlet is registered on this path.
> */
> @Property(name = "sling.servlet.paths", cardinality=Integer.MAX_VALUE)
> public static final String SERVLET_PATH = "/system/sling/logout";
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-2920) Wrong handling of Sling Filter ordering
[ https://issues.apache.org/jira/browse/SLING-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574410#comment-14574410 ] Olaf Otto commented on SLING-2920: -- I am afraid the change is a bigger issue then it may seem. It means that anyone upgrading to this version - AEM 6.1 users, in particular - will very likely experience issues. Moreover, code may have to be changed that is not under the control of the users. For instance, our customers are using feature packages provided by Adobe, the OSS community and various vendors, all of which would have to provide updated versions. I would thus strongly suggest to revert this change and provide a fix package to the upgrading users. Wrong handling of Sling Filter ordering --- Key: SLING-2920 URL: https://issues.apache.org/jira/browse/SLING-2920 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.2.8 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: Engine 2.3.4 Attachments: SLING-2920.patch It looks like the ordering of Sling Filters is not implemented as it is documented on [1]. The documented intent is: * service.ranking ordering with higher numbers being higher preference over lower numbers * filter.order ordering with lower numbers being higher preference over higher numbers * filter.order is ignored if service.ranking is defined * higher preferenced filters called before lower preferenced filters Actual implementation: * service.ranking ordering with lower numbers being higher preference over higher numbers * filter.order ordering with lower numbers being higher preference over higher numbers * filter.order is ignored if service.ranking is defined * higher preferenced filters called before lower preferenced filters As one can see, the service.ranking ordering is not properly implemented. It looks like this has been wrong since the first implementation as of SLING-1735 (Jan 2011). We can either live with this actual implementation and fix the documentation or fix the implementation at the cost of having to also fix any down-stream filter providers using service.ranking values as implemented (and not as documented). Discussion at http://sling.markmail.org/thread/h6uiveb2udw6y46q [1] http://sling.apache.org/documentation/the-sling-engine/filters.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag
Olaf Otto created SLING-4524: Summary: Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag Key: SLING-4524 URL: https://issues.apache.org/jira/browse/SLING-4524 Project: Sling Issue Type: Wish Reporter: Olaf Otto One of the most common use cases in JSP views is accessing the properties of the current resource. However, this currently requires explicit adaptation of the current resource to ValueMap, which is boilerplate. I'd thus love to see properties as one of the defaults provided by the before mentioned tag library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag
[ https://issues.apache.org/jira/browse/SLING-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-4524: - Comment: was deleted (was: Pull request: https://github.com/apache/sling/pull/74) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag Key: SLING-4524 URL: https://issues.apache.org/jira/browse/SLING-4524 Project: Sling Issue Type: Wish Reporter: Olaf Otto One of the most common use cases in JSP views is accessing the properties of the current resource. However, this currently requires explicit adaptation of the current resource to ValueMap, which is boilerplate. I'd thus love to see properties as one of the defaults provided by the before mentioned tag library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag
[ https://issues.apache.org/jira/browse/SLING-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369284#comment-14369284 ] Olaf Otto commented on SLING-4524: -- Pull request: https://github.com/apache/sling/pull/74 Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag Key: SLING-4524 URL: https://issues.apache.org/jira/browse/SLING-4524 Project: Sling Issue Type: Wish Reporter: Olaf Otto One of the most common use cases in JSP views is accessing the properties of the current resource. However, this currently requires explicit adaptation of the current resource to ValueMap, which is boilerplate. I'd thus love to see properties as one of the defaults provided by the before mentioned tag library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4507) Provide the sling whiteboard in the github repository
Olaf Otto created SLING-4507: Summary: Provide the sling whiteboard in the github repository Key: SLING-4507 URL: https://issues.apache.org/jira/browse/SLING-4507 Project: Sling Issue Type: Improvement Components: Best practices Reporter: Olaf Otto Currently, the whiteboard (http://svn.apache.org/repos/asf/sling/whiteboard/), containing various highly interesting experimental implementations (e.g., multitenancy support) is only available via SVN. It would be a great if the whiteboard also existed in git - e.g. as a standalone repo (like https://github.com/apache/flex-whiteboard) or as part of the trunk branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-3345) Regression of SLING-1414
Olaf Otto created SLING-3345:
Summary: Regression of SLING-1414
Key: SLING-3345
URL: https://issues.apache.org/jira/browse/SLING-3345
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 2.2.8
Environment: GNU/Linux 2.6.18-274.18.1.el5
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Reporter: Olaf Otto
The issue described in SLING-1414 arises only on JDK 1.7 on the previously
described Linux platform. It can be assumed that there is a platform-specific
deviation in compiler behavior, as the issue does not arise in MacOs or Windows
environments:
{code}
Caused by: java.lang.IllegalAccessException: Class javax.el.BeanELResolver can
not access a member of class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResource with
modifiers public
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:95)
at
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261)
at
java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253)
at java.lang.reflect.Method.invoke(Method.java:594)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (SLING-3319) ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions
[ https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-3319: - Summary: ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions (was: ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selctors or extensions) ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions -- Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto Original Estimate: 4h Remaining Estimate: 4h In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry only splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3319) ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions
[ https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-3319: - Description: In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. was: In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry only splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions -- Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto Original Estimate: 4h Remaining Estimate: 4h In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3319) ResourceProvider does not receive selectors or extensions when root path is resolved.
[ https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-3319: - Summary: ResourceProvider does not receive selectors or extensions when root path is resolved. (was: ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selectors or extensions) ResourceProvider does not receive selectors or extensions when root path is resolved. - Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto Original Estimate: 4h Remaining Estimate: 4h In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3319) ResourceProvider does not receive selectors or extensions when root path is resolved.
[ https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-3319: - Description: In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Thus a provider with a root path of /content/test/root is not found. The next iteration in ResourceResolver# resolveInternal(String absPath) will then provide /content/test/root to the ResourceProviderEntry. The provider is thus found, but invoked with /content/test/root (without any extensions or selectors). However when requesting a child resource: /content/test/root.html - [content, test, root, child.html] the provider for root is found and thus invoked with /content/test/root/child.html , i.e. including any selectors and suffixes. In essence, a ResourceProvider can not utilize any selectors or extensions to parametrize the resolution of its root resource. was: In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. ResourceProvider does not receive selectors or extensions when root path is resolved. - Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto Original Estimate: 4h Remaining Estimate: 4h In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Thus a provider with a root path of /content/test/root is not found. The next iteration in ResourceResolver# resolveInternal(String absPath) will then provide /content/test/root to the ResourceProviderEntry. The provider is thus found, but invoked with /content/test/root (without any extensions or selectors). However when requesting a child resource: /content/test/root.html - [content, test, root, child.html] the provider for root is found and thus invoked with /content/test/root/child.html , i.e. including any selectors and suffixes. In essence, a ResourceProvider can not utilize any selectors or extensions to parametrize the resolution of its root resource. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3319) ResourceProvider does not receive selectors or extensions when root path is resolved.
[
https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874150#comment-13874150
]
Olaf Otto commented on SLING-3319:
--
I have analyzed potential ways to alter this behavior. Removing the
extension(s) during the split() or during the resolution phase later on has
undesired side effects (i.e., bugs). For instance, the ResourceProviderEntry
infers semantics from the number of elements resolved:
{code:java}
// query: /libs/sling/servlet/default
// resource Provider: libs/sling/servlet/default/GET.servlet
// list will match libs, sling, servlet, default
// and there will be no resource provider at the end
if (entries.size() 0 entries.size() == elements.length) {
if (entries.get(entries.size() - 1).getResourceProviders().length == 0)
{
logger.debug(Resolved Synthetic {}, fullPath);
return new SyntheticResource(resourceResolver, fullPath,
ResourceProvider.RESOURCE_TYPE_SYNTHETIC);
}
}
{code}
I believe the underlying issue is a lack of distinction between the lookup path
(created by the ResourceResolverImpl using a ResourcePathIterator) and the
original path as passed to the ResourceResolver. In my opinion, the original
path should be preserved and passed to the resolver obtained via the path
created by the ResourcePathIterator.
I have modified the ResourceResolverImpl to this extend, and ran both the unit
tests and some integration tests against a CMS project using Sling - so far I
spotted no error. However, this is a very sensitive change and must be reviewed
with care.
ResourceProvider does not receive selectors or extensions when root path is
resolved.
-
Key: SLING-3319
URL: https://issues.apache.org/jira/browse/SLING-3319
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: Resource Resolver 1.0.6
Reporter: Olaf Otto
Original Estimate: 4h
Remaining Estimate: 4h
In order to find and sort ResourceProviders, the ResourceProviderEntry class
from org.apache.sling.resourceprovider splits the request path into segments,
subsequently traversing the segments to find provides with a root matching
the entire path up to the current segment. However, The function
split(String) of ResourceProviderEntry splits by /, thus resulting in the
last segment containing any selectors and extensions of the current path,
like so:
/content/test/root.html - [content, test, root.html].
Thus a provider with a root path of /content/test/root is not found. The next
iteration in ResourceResolver# resolveInternal(String absPath) will then
provide /content/test/root to the ResourceProviderEntry. The provider is thus
found, but invoked with /content/test/root (without any extensions or
selectors).
However when requesting a child resource:
/content/test/root.html - [content, test, root, child.html]
the provider for root is found and thus invoked with
/content/test/root/child.html , i.e. including any selectors and suffixes.
In essence, a ResourceProvider can not utilize any selectors or extensions to
parametrize the resolution of its root resource.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (SLING-3319) ResourceProvider does not receive selectors or extensions when root path is resolved.
[ https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-3319: - Attachment: SLING-3319.patch patchfile adding original path preservation to the resource resolver ResourceProvider does not receive selectors or extensions when root path is resolved. - Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto Attachments: SLING-3319.patch Original Estimate: 4h Remaining Estimate: 4h In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Thus a provider with a root path of /content/test/root is not found. The next iteration in ResourceResolver# resolveInternal(String absPath) will then provide /content/test/root to the ResourceProviderEntry. The provider is thus found, but invoked with /content/test/root (without any extensions or selectors). However when requesting a child resource: /content/test/root.html - [content, test, root, child.html] the provider for root is found and thus invoked with /content/test/root/child.html , i.e. including any selectors and suffixes. In essence, a ResourceProvider can not utilize any selectors or extensions to parametrize the resolution of its root resource. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3319) ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selctors or extensions
Olaf Otto created SLING-3319: Summary: ResourceProviderEntry fails to resolve resource provider when providers root path is resolved with selctors or extensions Key: SLING-3319 URL: https://issues.apache.org/jira/browse/SLING-3319 Project: Sling Issue Type: Bug Components: JCR Affects Versions: Resource Resolver 1.0.6 Reporter: Olaf Otto In order to find and sort ResourceProviders, the ResourceProviderEntry class from org.apache.sling.resourceprovider splits the request path into segments, subsequently traversing the segments to find provides with a root matching the entire path up to the current segment. However, The function split(String) of ResourceProviderEntry only splits by /, thus resulting in the last segment containing any selectors and extensions of the current path, like so: /content/test/root.html - [content, test, root.html]. Consequently, a provider with the root path /content/test/root is not found, but when a child of that path is requested, the provider is found. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] Commented: (SLING-1708) contrib/scripting/velocity is missing suitable resourceloader for the JCR
[ https://issues.apache.org/jira/browse/SLING-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910139#action_12910139 ] Olaf Otto commented on SLING-1708: -- Well, this does work, in a sense of including yet another resource, however this includes the result of the call to the script. #include would insert the unevaluated velocity code and expose all variables and macro definitions of the included resource, $sling.include() does not. contrib/scripting/velocity is missing suitable resourceloader for the JCR - Key: SLING-1708 URL: https://issues.apache.org/jira/browse/SLING-1708 Project: Sling Issue Type: Bug Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Fix For: Scripting Velocity 2.0.0 Original Estimate: 4h Remaining Estimate: 4h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The velocity resource manager (org.apache.velocity.runtime.resource.ResourceManagerImpl) has, by default, only an org.apache.velocity.runtime.resource.loader.FileResourceLoader instance. This resourceloader cannot load resources JCR resources as it attempts to access the filesystem. To reproduce, simply create a .vlt script and add an include directive: template1.vlt: #include(/path/to/template2.vlt) This will fail: org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource '/path/to/template2.vlt' at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:483) at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354) at org.apache.velocity.runtime.RuntimeInstance.getContent(RuntimeInstance.java:1445) at org.apache.velocity.runtime.directive.Include.renderOutput(Include.java:229) at org.apache.velocity.runtime.directive.Include.render(Include.java:155) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.RuntimeInstance.render(RuntimeInstance.java:1277) at org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1216) A suitable resource loader should be provided to the VelocityEngine instance (perhaps in the VelocityTemplatesScriptEngine). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906469#action_12906469
]
Olaf Otto commented on SLING-1700:
--
r990926 works, thanks!
However, I'd really appreciate two more minor changes before a release in the
eval(..) method:
1) Remove the useless w.toString() invocation (line 94)
2) Include the stacktrace of the exception (Line 96)
Thanks,
Olaf
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: SLING-1700-mykee.patch, SLING-1700-ootto.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904133#action_12904133
]
Olaf Otto commented on SLING-1700:
--
Yes, the patch looks good, however it also needs to be applied to every eval()
call (this is where my problem originally occurred, not in the init()
invocation of the velocity engine). I will attach an updated version of the
patch.
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: SLING-1700-mykee.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Otto updated SLING-1700:
-
Attachment: patch-v2.txt
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: patch-v2.txt, SLING-1700-mykee.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Otto updated SLING-1700:
-
Attachment: SLING-1700-ootto.patch
Version 2 of the classloading patch for velocity.
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: SLING-1700-mykee.patch, SLING-1700-ootto.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Otto updated SLING-1700:
-
Attachment: (was: patch-v2.txt)
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: SLING-1700-mykee.patch, SLING-1700-ootto.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904208#action_12904208
]
Olaf Otto commented on SLING-1700:
--
I've successfully tested the patch SLING-1700-ootto.patch with
scripting-core 2.0.9.R897146, scripting-api 2.1.1.SNAPSHOT (rev. 945149).
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Assignee: Mike Müller
Attachments: SLING-1700-mykee.patch, SLING-1700-ootto.patch
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1708) contrib/scripting/velocity is missing suitable resourceloader for the JCR
contrib/scripting/velocity is missing suitable resourceloader for the JCR - Key: SLING-1708 URL: https://issues.apache.org/jira/browse/SLING-1708 Project: Sling Issue Type: Bug Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The velocity resource manager (org.apache.velocity.runtime.resource.ResourceManagerImpl) has, by default, only an org.apache.velocity.runtime.resource.loader.FileResourceLoader instance. This resourceloader cannot load resources JCR resources as it attempts to access the filesystem. To reproduce, simply create a .vlt script and add an include directive: template1.vlt: #include(/path/to/template2.vlt) This will fail: org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource '/path/to/template2.vlt' at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:483) at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354) at org.apache.velocity.runtime.RuntimeInstance.getContent(RuntimeInstance.java:1445) at org.apache.velocity.runtime.directive.Include.renderOutput(Include.java:229) at org.apache.velocity.runtime.directive.Include.render(Include.java:155) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.RuntimeInstance.render(RuntimeInstance.java:1277) at org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1216) A suitable resource loader should be provided to the VelocityEngine instance (perhaps in the VelocityTemplatesScriptEngine). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903365#action_12903365
]
Olaf Otto commented on SLING-1700:
--
I thought it was an import declaration issue, too - however the bundle in
question did not import anything from the standalone velocity bundle. I believe
it is an issue with the ClassUtils shipped with velocity: They might break
bundle isolation via the thread context classloader:
53 public static Class getClass(String clazz) throws
ClassNotFoundException
54 {
55 /**
56* Use the Thread context classloader if possible
57*/
58 ClassLoader loader =
Thread.currentThread().getContextClassLoader();
59 if (loader != null)
60 {
61 try
62 {
63 return Class.forName(clazz, true, loader);
64 }
65 catch (ClassNotFoundException E)
66 {
67 /**
68* If not found with ThreadContext loader, fall thru to
69* try System classloader below (works around bug in
ant).
70*/
71 }
72 }
73 /**
74* Thread context classloader isn't working out, so use system
loader.
75*/
76 return Class.forName(clazz);
77 }
IMO all required ro reproduce the issue is to have botht the velocity scripting
support bundle and a standalone velocity bundle (for instance from the
sprigsource repo) in felix and call an arbitrary vm script.
Anyhow, I do agree that embedding dependencies might not always be a bad thing
- however the scripting support does not appear to be tied to a specific
velocity version, it pretty much relies on a small part of the public velocity
API. Being a developer I would appreciate being able to update the velocity
version, even if within certain boundaries, for instance [1.6, 1.7).
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903374#action_12903374
]
Olaf Otto commented on SLING-1700:
--
You can fix the classloader issue if you set the thrad context class loader
before calling into the Velocity code (and reset afterwards, of course, to
not create memory holes).
We do this in a number of places in our script engines and it works
flawlessly.
Right, that sounds like a very good approach. That should be done regardless of
how velocity is integrated.
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903441#action_12903441
]
Olaf Otto commented on SLING-1700:
--
One more thought: I am wondering what classloader should be provided as the
context classloader. My guess is using the classloader of the
VelocityTemplatesScriptEngineFactory (presumably the bundle classloader of the
velocity scripting bundle). However other implementations such as the JSP
engine use the dynamic classloader obtained from the DynamicClassLoaderManager.
This however would be a problem if a velocity bundle is installed (and velocity
remains embedded), would it? Would you agree on using the velocity scripting
bundle classloader?
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle is
also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1702) contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs workaround in case of engine instantiation errors
contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs
workaround in case of engine instantiation errors
---
Key: SLING-1702
URL: https://issues.apache.org/jira/browse/SLING-1702
Project: Sling
Issue Type: Improvement
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The (terrible!) Sun implementation of javax.script.ScriptEngineManager silently
discards all exceptions thrown when a scripting factory creates an engine:
...
private static final boolean DEBUG = false;
...
} catch (Exception exp) {
if (DEBUG) exp.printStackTrace();
}
This hides any error with the velocity configuration from the user. Thus the
VelocityTemplatesScriptEngineFactory should provide a log-and-re-throw
workaround, like so:
...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private final Logger logger = LoggerFactory.getLogger(getClass());
public ScriptEngine getScriptEngine() {
ScriptEngine engine;
try {
engine = new VelocityTemplatesScriptEngine(this);
} catch (RuntimeException e) {
logger.error(Unable to instantiate the velocity
template engine., e);
throw e;
}
return engine;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1702) contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs workaround in case of engine instantiation errors
[
https://issues.apache.org/jira/browse/SLING-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902854#action_12902854
]
Olaf Otto commented on SLING-1702:
--
Concerning the flawed Sun implementation: The discarding of exceptions affects
(at least) JDK 1.6.0 U 21 for Linux / 32 bit
contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs
workaround in case of engine instantiation errors
---
Key: SLING-1702
URL: https://issues.apache.org/jira/browse/SLING-1702
Project: Sling
Issue Type: Improvement
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The (terrible!) Sun implementation of javax.script.ScriptEngineManager
silently discards all exceptions thrown when a scripting factory creates an
engine:
...
private static final boolean DEBUG = false;
...
} catch (Exception exp) {
if (DEBUG) exp.printStackTrace();
}
This hides any error with the velocity configuration from the user. Thus the
VelocityTemplatesScriptEngineFactory should provide a log-and-re-throw
workaround, like so:
...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private final Logger logger = LoggerFactory.getLogger(getClass());
public ScriptEngine getScriptEngine() {
ScriptEngine engine;
try {
engine = new VelocityTemplatesScriptEngine(this);
} catch (RuntimeException e) {
logger.error(Unable to instantiate the velocity
template engine., e);
throw e;
}
return engine;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
[ https://issues.apache.org/jira/browse/SLING-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-1701: - Attachment: (was: VelocityTemplatesScriptEngine.java) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Original Estimate: 1h Remaining Estimate: 1h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
[ https://issues.apache.org/jira/browse/SLING-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-1701: - Attachment: VelocityTemplatesScriptEngine.java Refactored version of rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/src/main/java/org/apache/sling/scripting/velocity/VelocityTemplatesScriptEngine.java contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Attachments: VelocityTemplatesScriptEngine.java Original Estimate: 1h Remaining Estimate: 1h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
