[jira] Reopened: (SLING-952) ant task in dojo build does not use Maven proxy settings for downloading
[ https://issues.apache.org/jira/browse/SLING-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened SLING-952: - Contrib build fails after this commit: [taskdef] Could not load definitions from resource net/sf/antcontrib/antcontrib.properties. It could not be found. [HUDSON] Archiving https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/pom.xml to /home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.dojo/builds/2010-08-28_18-14-47/archive/org.apache.sling/org.apache.sling.extensions.dojo/1.1.0.002-SNAPSHOT/pom.xml Reopening for investigation ant task in dojo build does not use Maven proxy settings for downloading Key: SLING-952 URL: https://issues.apache.org/jira/browse/SLING-952 Project: Sling Issue Type: Bug Components: Extensions Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor Attachments: pom.xml.noproxy.patch The ant get task used in /contrib/extensions/dojo/pom.xml does not seem to use the current Maven proxy settings. Workaround is to download the dojo release file manually and place it in the download-cache folder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-952) ant task in dojo build does not use Maven proxy settings for downloading
[ https://issues.apache.org/jira/browse/SLING-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-952. - Resolution: Fixed Plugin dependencies are not recognized since the parent pom already has an antrun plugin configuration. As a workaround added the ant dependencies as provided dependencies and referring to them as maven.compile.classpath reference in Rev. 990534. ant task in dojo build does not use Maven proxy settings for downloading Key: SLING-952 URL: https://issues.apache.org/jira/browse/SLING-952 Project: Sling Issue Type: Bug Components: Extensions Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor Attachments: pom.xml.noproxy.patch The ant get task used in /contrib/extensions/dojo/pom.xml does not seem to use the current Maven proxy settings. Workaround is to download the dojo release file manually and place it in the download-cache folder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r988161 - in /sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr: JcrNodeResource.java JcrPropertyResource.java
Hi,
On 23.08.2010 17:50, cziege...@apache.org wrote:
Author: cziegeler
Date: Mon Aug 23 15:50:51 2010
New Revision: 988161
URL: http://svn.apache.org/viewvc?rev=988161view=rev
Log:
Use static loggers for data objects
Is there a particular reason for making the GC work harder ?
Regards
Felix
Modified:
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrPropertyResource.java
Modified:
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
URL:
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java?rev=988161r1=988160r2=988161view=diff
==
---
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
(original)
+++
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
Mon Aug 23 15:50:51 2010
@@ -57,7 +57,7 @@ class JcrNodeResource extends JcrItemRes
private static final String UNSET_RESOURCE_SUPER_TYPE = unset;
/** default log */
-private final Logger log = LoggerFactory.getLogger(getClass());
+private static final Logger LOGGER =
LoggerFactory.getLogger(JcrNodeResource.class);
private final Node node;
@@ -126,12 +126,12 @@ class JcrNodeResource extends JcrItemRes
return (Type) new JcrModifiablePropertyMap(getNode(),
this.dynamicClassLoader);
} catch (AccessControlException ace) {
// the user has no write permission, cannot adapt
-log.debug(
+LOGGER.debug(
adaptTo(PersistableValueMap): Cannot set properties on
{},
this);
} catch (RepositoryException e) {
// some other problem, cannot adapt
-log.debug(
+LOGGER.debug(
adaptTo(PersistableValueMap): Unexpected problem for
{},
this);
}
@@ -187,7 +187,7 @@ class JcrNodeResource extends JcrItemRes
data = ((Property) item);
} catch (ItemNotFoundException infe) {
// we don't actually care, but log for completeness
-log.debug(getInputStream: No primary items for
+LOGGER.debug(getInputStream: No primary items for
+ toString(), infe);
data = null;
}
@@ -206,7 +206,7 @@ class JcrNodeResource extends JcrItemRes
}
} catch (RepositoryException re) {
-log.error(getInputStream: Cannot get InputStream for +
this,
+LOGGER.error(getInputStream: Cannot get InputStream for +
this,
re);
}
}
@@ -219,7 +219,7 @@ class JcrNodeResource extends JcrItemRes
try {
return URLFactory.createURL(node.getSession(), node.getPath());
} catch (Exception ex) {
-log.error(getURL: Cannot create URL for + this, ex);
+LOGGER.error(getURL: Cannot create URL for + this, ex);
}
return null;
@@ -235,7 +235,7 @@ class JcrNodeResource extends JcrItemRes
getNode().getNodes(), this.dynamicClassLoader);
}
} catch (RepositoryException re) {
-log.error(listChildren: Cannot get children of + this, re);
+LOGGER.error(listChildren: Cannot get children of + this, re);
}
return Collections.Resource emptyList().iterator();
@@ -268,12 +268,12 @@ class JcrNodeResource extends JcrItemRes
try {
metadata.setModificationTime(prop.getLong());
} catch(ValueFormatException vfe) {
-log.debug(Property {} cannot be converted to a long,
ignored ({}),
+LOGGER.debug(Property {} cannot be converted to a long,
ignored ({}),
prop.getPath(), vfe);
}
}
} catch (RepositoryException re) {
-log.info(
+LOGGER.info(
setMetaData: Problem extracting metadata information for
+ getPath(), re);
}
Modified:
sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrPropertyResource.java
URL:
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi, This is already the case because all resource providers on a certain level are ordered according to their ServiceReference.compareTo. Thus the service.ranking and service.id are considered for the ordering. Regards Felix On 24.08.2010 17:52, Carsten Ziegeler wrote: Mike Müller wrote Hi That seems to be a good way to implement it. IIRC the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. If that is correct the SyntheticResourceProvider (which I rather would name something like PathNodeProvider) should be registered for /, where also the JcrResourceProvider is registered. The question is now, how the resource provider which are registered for the same path could be further ordered (the service id doesn't seem to be a good idea). Any idea? We could use service.ranking property - the standard way of defining an order in such cases. Carsten
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi, On 24.08.2010 09:51, Julian Sedding wrote: Hi Felix The proposal looks good, +1. I've some additional thoughts: If resources are provided by several ResourceProviders, does it matter which one provides the resource? E.g. the sling:resourceType might vary. So I believe that the order in which ResourceProviders are asked to provide a certain resource needs to be guaranteed. It is: providers are asked from the bottom of the tree to the top, thus giving the longest prefix-path matching provider first. If on a certein tree level more than one provider is registered, these providers are asked in order of their ranking (service.ranking and service.id service registration properties). If this assumption holds true, couldn't the synthetic resources be provided by a SyntheticResourceProvider, which would be internal to the ResourceResolver. This SyntheticResourceProvider should be registered as the last one in the list of ResourceProviders. The synthetic resources could then be pre-created upon registration of servlets or ResourceProviders. Reusing the ResourceProvider concept to handle this special case should make it less special and thus would IMHO allow keep the code simple. WDYT? I am not sure, whether this really helps or just makes the code more complicated. We in fact have an internal tree structure of resource providers. The actual resource providers are registered at varous levels in thise tree. We walk this tree to find the resources to list. So in fact this tree is the virtual SyntheticResource provider. Regards Felix Regards Julian On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Here is what I would see to be intended. For case (1) the ResourceResolver must mix the results of calling listChildren(/for/bar) on all resource providers providing resource at or below said path. In this case the BundleResourceProvider and the JcrResourceProvider. For case (2) the ResourceResolver must create these intermediary SyntheticResource instances to be able to traverse down to the mount point of provided resources. Case (2) seems to work, though: when you deploy my whiteboard WebDAV bundle, you will for example see the subtree below /libs, e.g. /libs/sling/redirect. This subtree is entirely synthetic and created on the fly. In the case of the ServletResourceProvider part of the work is done in the ServletResourceProvider (see ServletResourceIterator.seek() method). The ResourceResolver calls the ResourceProvider.listChildren method on each resource provider registered with a path which is a substring of the parent path or which includes the parent path. Maybe this kind of code should be moved to the ResourceResolver creating these synthetic intermediaries for locations below which a ResourceProvider is attached. Now, the BundleResourceProvider is not operating like this. For example there is the Sling POST Servlet bundle registering the /system/sling.js script. This script is never returned by the BundleResourceProvider's listChildren implementation. So what we probably should do is the following: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. WDYT ? Regards Felix Regards Felix On 23.08.2010 10:17, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected
[jira] Created: (SLING-1705) Proactively set length of jcr:data property for nt:file node resources
Proactively set length of jcr:data property for nt:file node resources -- Key: SLING-1705 URL: https://issues.apache.org/jira/browse/SLING-1705 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.8 A resource wrapping a node of type nt:file provides access to the jcr:content/jcr:data by an adapter to the InputStream. In this case, the Property.getLength() value of the jcr:content/jcr:data property can be considered the content length of the resource and should be set in the ResourceMetadata accordingly. Currently (as of SLING-288) the content length metadata property is only set when the resource is adapted to an InputStream. Same holds for Property-based resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1705) Proactively set length of jcr:data property for nt:file node resources
[ https://issues.apache.org/jira/browse/SLING-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1705. -- Resolution: Fixed Implemented proactively setting the content length in the resource metadata in Rev. 990610. Proactively set length of jcr:data property for nt:file node resources -- Key: SLING-1705 URL: https://issues.apache.org/jira/browse/SLING-1705 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.8 A resource wrapping a node of type nt:file provides access to the jcr:content/jcr:data by an adapter to the InputStream. In this case, the Property.getLength() value of the jcr:content/jcr:data property can be considered the content length of the resource and should be set in the ResourceMetadata accordingly. Currently (as of SLING-288) the content length metadata property is only set when the resource is adapted to an InputStream. Same holds for Property-based resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Müller resolved SLING-1671. Assignee: Mike Müller (was: Clemens Wyss) Resolution: Fixed commited in r990613, more to come in following issue... New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Assignee: Mike Müller Priority: Minor Attachments: sling-1671-clemens.patch + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904004#action_12904004 ] Mike Müller commented on SLING-1671: There are still some minor issues, but as a work in progress I commited a first shot of he improvments to let interested persons participate. New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Assignee: Clemens Wyss Priority: Minor Attachments: sling-1671-clemens.patch + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1672) resource.resourceResolver.listChildren only enlists jcr nodes but not all child resources
[ https://issues.apache.org/jira/browse/SLING-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904016#action_12904016 ] Felix Meschberger commented on SLING-1672: -- Rev. 990628: Created a new ResourceIterator class from the internal class of the ResourceProviderEntry.listChildren method. This class is now directly created from the JcrResourceResolver.listChildren method. The ResourceProviderEntry.listChildren method is removed. Adapted the Servlet Resolver ResourceProvider implementation in Rev. 990629 to not generate the synthetic resource iterator entries for the ResourceResovler.listChildren method any more because this is now done by the JcrResourceResolver. resource.resourceResolver.listChildren only enlists jcr nodes but not all child resources - Key: SLING-1672 URL: https://issues.apache.org/jira/browse/SLING-1672 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.6 Environment: sling from trunk (as of August 20th 2010) Reporter: Clemens Wyss Assignee: Felix Meschberger Fix For: JCR Resource 2.0.8 in my esp-script I have the follwoing line: var childResources = request.resourceResolver.listChildren(resource ); In my pom.xml I have the follwoing declaration: Sling-Bundle-Resources /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer /Sling-Bundle-Resources i.e. I map /res/sling/explorer to /libs/sling/explorer. And I can directly access the files beneath /res/sling/explorer, e.g. http://localhost:8080/res/sling/explorer/css/explorer.css. I.e. resolving seems to work But when I enlist (which end up in BundleResourceProvider#listChildren()) on the root (/) I don't see 'res' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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
]
Mike Müller reassigned SLING-1700:
--
Assignee: Mike Müller
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
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
]
Mike Müller updated SLING-1700:
---
Attachment: SLING-1700-mykee.patch
In a first step I created a patch which should fix the classloader problem.
Olaf can you give it a try and let me know if this works for your setup.
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] 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=12904018#action_12904018
]
Mike Müller commented on SLING-1702:
If we want to implement a workaround this vm implementation specific problem,
we should find a way to do this in AbstractScriptEngineFactory because it
affects all implementations of ScriptEngineFactory.
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] Issue Comment Edited: (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=12904018#action_12904018
]
Mike Müller edited comment on SLING-1702 at 8/29/10 3:25 PM:
-
If we want to implement a workaround for this vm implementation specific
problem, we should find a way to do this in AbstractScriptEngineFactory because
it affects all implementations of ScriptEngineFactory.
was (Author: mykee):
If we want to implement a workaround this vm implementation specific
problem, we should find a way to do this in AbstractScriptEngineFactory because
it affects all implementations of ScriptEngineFactory.
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] 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=12904023#action_12904023
]
Felix Meschberger commented on SLING-1700:
--
BTW: the patch looks good (not tested, just looked at it ;-). Thanks
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.
Hudson build became unstable: sling-trunk-1.6 #543
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/543/changes
Hudson build became unstable: sling-trunk -1.6 » Apache Sling Launchpad Testing #543
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/543/
Hudson build is back to normal : sling-contrib- 1.5 » Apache Sling Dojo JavaScript Library #572
See https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/572/changes
Build failed in Hudson: sling-contrib-1.5 » Apache Sling Launchpad Contrib Testing #572
See https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/572/ -- [...truncated 19 lines...] [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.commons.classloader/1.2.1-SNAPSHOT/org.apache.sling.commons.classloader-1.2.1-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.commons.classloader-1.2.1-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.api/2.1.0/org.apache.sling.api-2.1.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.api-2.1.0.jar [INFO] snapshot org.apache.sling:org.apache.sling.settings:0.1.0-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.settings/0.1.0-SNAPSHOT/org.apache.sling.settings-0.1.0-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.settings-0.1.0-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.core/1.0.2/org.apache.sling.auth.core-1.0.2.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.core-1.0.2.jar [INFO] snapshot org.apache.sling:org.apache.sling.engine:2.0.7-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.engine/2.0.7-SNAPSHOT/org.apache.sling.engine-2.0.7-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.engine-2.0.7-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.openid/1.0.0/org.apache.sling.auth.openid-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.openid-1.0.0.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.form/1.0.0/org.apache.sling.auth.form-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.form-1.0.0.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.selector/1.0.0/org.apache.sling.auth.selector-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.selector-1.0.0.jar [INFO] snapshot org.apache.sling:org.apache.sling.adapter:2.0.5-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.adapter/2.0.5-SNAPSHOT/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.resolver:2.0.9-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.resolver/2.0.9-SNAPSHOT/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.get:2.0.9-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.get/2.0.9-SNAPSHOT/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/ws/target/launchpad-bundles/resources/bundles/0/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.post:2.0.5-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from
Build failed in Hudson: sling-contrib-1.5 #572
See https://hudson.apache.org/hudson/job/sling-contrib-1.5/572/changes Changes: [mykee] SLING-1671 replaced jquery 1.3.x with 1.4.x [mykee] SLING-1671 New features for jQuery JCR Explorer - step 1 [fmeschbe] SLING-952 plugin dependencies are not recognized since the parent pom already has an antrun plugin configuration. As a workaround added the ant dependencies as provided dependencies and referring to them as maven.compile.classpath reference -- [...truncated 3468 lines...] [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.openid/1.0.0/org.apache.sling.auth.openid-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.openid-1.0.0.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.form/1.0.0/org.apache.sling.auth.form-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.form-1.0.0.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.selector/1.0.0/org.apache.sling.auth.selector-1.0.0.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.auth.selector-1.0.0.jar [INFO] snapshot org.apache.sling:org.apache.sling.adapter:2.0.5-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.adapter/2.0.5-SNAPSHOT/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.resolver:2.0.9-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.resolver/2.0.9-SNAPSHOT/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.get:2.0.9-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.get/2.0.9-SNAPSHOT/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.servlets.post:2.0.5-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.post/2.0.5-SNAPSHOT/org.apache.sling.servlets.post-2.0.5-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.servlets.post-2.0.5-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.jcr.contentloader:2.0.7-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.contentloader/2.0.7-SNAPSHOT/org.apache.sling.jcr.contentloader-2.0.7-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.jcr.contentloader-2.0.7-SNAPSHOT.jar [INFO] snapshot org.apache.sling:org.apache.sling.jcr.resource:2.0.7-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.resource/2.0.7-SNAPSHOT/org.apache.sling.jcr.resource-2.0.7-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.jcr.resource-2.0.7-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.ocm/2.0.4-incubator/org.apache.sling.jcr.ocm-2.0.4-incubator.jar to https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/0/org.apache.sling.jcr.ocm-2.0.4-incubator.jar [INFO] snapshot org.apache.sling:org.apache.sling.jcr.classloader:3.1.3-SNAPSHOT: checking for updates from scala-tools.org [INFO] Copying bundle from
Hudson build became unstable: sling-trunk-1.5 #851
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/851/changes
