[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
